I cannot fully restore one package in renv lock file, but I am able to install different version of this package. So I wonder if I can manually overwrite package version in lock file. Do I just need to replace version number? Should I change hash as well? What are the consequences?
You can -- renv.lock is just JSON, so you can modify it as needed if you need to tweak a particular entry. (Or, you can use renv::record(<package>#<version>) to explicitly update the lockfile using renv APIs.)
If you're changing entries in renv.lock, you should normally remove the Hash component for modified entries. The hash is used for caching; it allows renv::restore() to restore a package from the global renv cache if available, thereby avoiding a retrieve + build + install of the package.
If it is not set, then renv will not use the cache and instead always try to retrieve the package from the declared source (which seems appropriate for your case).
Related
I know there are plenty of ways to install packages but I obtained a zipped folder containing lots of folders with r packages. Is that ok to simply unzip the folder, copy all the folders and paste them to R-3.6.1\library location? Will that work properly?
You're talking about the installed package folders that were built and installed on another computer?
You'd want to be sure they are from the same operating system and version of R.
It also depends if there are any unmet or potentially conflicting dependencies. If not, in theory it should work.
But you'll then get notified of package updates. So it will only save you time installing them in the first place.
You could always switch between the package libs location when starting RStudio, by setting the "R_LIBS_USER" environment variable. Then update those packages (and get a sense of how safe it is), and you'll probably run into less chance of issues when you soft-copy them across to your primary location.
And please backup the primary location first if you need to restore it to that point.
I want to be able to import or using a package that I'm writing in a directory ~/projects/ExamplePkg from my main Julia REPL / from another project or environment.
By ]foo I mean "use the foo command at the Julia Pkg REPL". Type ] at the Julia REPL to enter the Pkg REPL. Use ]help <command name> for more info or check the link below.
Ensure that your package has a Project.toml that gives it a UUID and names it (generate one with ]generate from the Julia REPL or with the PkgTemplates package) and that it is in a git repo with at least one commit including all the relevant files.
Then choose how you would like to use the package.
You probably want to run ]dev ~/projects/ExamplePkg:
If dev is used on a local path, that path to that package is recorded and used when loading that package. The path will be recorded relative to the project file, unless it is given as an absolute path.
If you use dev and you change the dependencies in the dev'd package, then you should probably run ]resolve in all environments that depend on the package.
Or you can run ]add ~/projects/ExamplePkg:
Instead of giving a URL of a git repo to add we could instead have given a local path to a git repo. This works similarly to adding a URL. The local repository will be tracked (at some branch) and updates from that local repo are pulled when packages are updated. Note that changes to files in the local package repository will not immediately be reflected when loading that package. The changes would have to be committed and the packages updated in order to pull in the changes.
In Julia versions <1.4: If you accidentally ]add a package before the git repo is set up correctly then you might get ERROR: GitError(Code:EUNBORNBRANCH, Class:Reference, reference 'refs/heads/master' not found). Unfortunately, Julia will probably have cached the bad repo, and you will need to remove that from ~/.julia/clones/<gibberish>/. You can find the dir to remove with grep: $ grep ExamplePkg ~/.julia/clones/*/config.
Documentation: https://julialang.github.io/Pkg.jl/v1/managing-packages/
you can try
path_to_package = "~/projects/ExamplePkg"
push!(LOAD_PATH,path_to_package)
# then use it, ExamplePkg is the package's name
using ExamplePkg
But you have to run codes above whenever you restart Julia.
reference is Workflow tips-Julia Documentation
I'm setting up a git workflow with my R project using packrat. Everytime I packrat::snapshot() my workspace, the file packrat.lock changes with the new packages/versions etc, but it also changes the Hash line for each package, which is a bit annoying when checking file diffs to see what changed from one commit to another.
Is this Hash really necessary? If not, is there any way to disable it?
The hash is generated by the hidden hash() function in packrat library, and it serves as a package consistency check.
The algorithm generates an md5sum that is based on the DESCRIPTION file included in the package tarball, but there is additional logic involved, see lines #103-#107 in the packrat/R/cache.R source at Github.
In order to obtain the HASH that packrat expects to find in the packrat.lock file a direct call to the hash() function must be made. This function is not exposed in the compiled package, so the only way to access it is to use the packrat source.
Obtain a copy of the source of the packrat library from CRAN with the correct version
Extract it into a folder (in my example it is packrat-0.5.0)
Start an R session
The following lines demonstrate how to generate the hash for the package BH-1.66.0-1 (4cc8883584b955ed01f38f68bc03af6d):
# md5sum() function is neeeded
library(tools)
# relevant source code files are loaded
source('packrat-0.5.0/R/utils.R') # readDcf() function
source('packrat-0.5.0/R/cache.R') # packrat's hash() function
# execute the hash() function on the DESCRIPTION file in the package
print(hash('/usr/local/lib/R/site-library/BH/DESCRIPTION'))
This should return the correct HASH of 4cc8883584b955ed01f38f68bc03af6d.
I am not aware of any options in packrat that would allow you to disable HASH checking. If your goal is to manually modify the packrat.lock file to alter a package version, it is certainly possible by performing this trick.
This could help overcome some minor dependency issues. However, there are two dangers:
such a package version change may start a cascade of dependency upgrade requirements
errors appear in your app because of compatibility issues
Is there any documentation on manually installing a package in a user library when the R.home() path is locked down and incomplete (no etc, no bin, just library?) The system does NOT support shelling out to execute R CMD, which I believe standard R does.
I would like to build existing source packages (from CRAN) and install into a user library directory, so that I can use the library() function and get all the usual namespace and *.Rdx and *.Rdb files.
At the moment, I'm plodding through install.packages, tools::.build_package, and tools:::.install.packages source, using a standard MacOS R and the r source. Hopefully this has been documented in a more user-friendly fashion and my google searches have missed it.
Thanks.
You don't need to use a different install.packages method, rather you only need to specify a writable location for storing packages and give it precedence over the system default one. A simple way to accomplish this is to set an R_LIBS environment variable. For instance, in my .bashrc I have
export R_LIBS='/home/username/.local/lib/R-3.3.3'
Then, by default, all packages are installed here. Further, packages installed both here and the system-wide location will give priority to the ones here when loading.
You can verify that the location is being used by checking .libPaths() in your R session.
I have been using git for a while but just recently started using packrat. I would like my repository to be self contained but at the same time I do not want to include CRAN packages as they are available. It seems once R is opened in a project with packrat it will try to use packages from project library; if they are not available then it will try to install from src in the project library; if they are not available it will look at libraries installed in that computer. If a library is not available in the computer; would it look at CRAN next?
What files should I include in my git repo as a minimum (e.g., packrat.lock)?
You can choose to set an external CRAN-like repository with the source tarballs of the packages and their versions that you'd like available for your project. The default behaviour, however, is to look to CRAN next, as you've identified in your question. Check out the packrat.lock file, you will see that for each package you use in packrat, there is an option called source: CRAN (if you've downloaded the file from CRAN, that is).
When you have a locally stored package source file, the contents of the lockout for said package change to the following:
Package: FooPackage
Source: source
Version: 0.4-4
Hash: 44foo4036fb68e9foo9027048d28
SourcePath: /Users/MyName/Documents/code/myrepo/RNetica
I'm a bit unclear on your final question: What files should I include in my git repo as a minimum (e.g., packrat.lock)? But I'm going to take this as a) combination of what files should be present for packrat to run, and b) which of those files should be committed to the git-repo. To answer the first question, I illustrate with initialising packrat on an existing R project.
When you run packrat::init(), two important things happen (among others):
1. All the packrat scaffolding, including source tarballs etc are created under: PackageName/packrat/.
2. packrat/lib*/ is added to your .gitignore file.
So from this, we can see that anything under packrat/lib*/ doesn't need to be committed to your git-repo. This leaves the following 3 files to be committed:
packrat/init.R
packrat/packrat.lock
packrat/packrat.opts
packrat.lock is needed for collaborating with others through a version control system; it helps keep your private libraries in sync. packrat.opts allows you to specify different project specific options for packrat. The file is automatically generated using get_opts and set_opts. Committing this file to the git-repo will ensure that any options you specify are maintained for all collaborators. A final file to be committed to the repo is .Rprofile. This file tells R to use the private package library (when R is started from the project directory).
Depending on your needs, you can choose to commit the source tar balls to the repository, or not. If you don't want them available in your git-repo, you simply add packrat/src/ to the .gitignore. But, this will mean that anyone accessing the git-repo will not have access to the package source code, and the files will be downloaded from CRAN, or from wherever the source line dictates within the packrat.lock file.
From your question, it sounds like committing the packrat/src/ folder contents to your repo might be what you need.