Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello
I have to manage the installation of R and his packages at the system level. And I would like to handle it like I handle Python modules, with virtualenv to allow all R users to use the same packrat like I do in python. Thereby I can install multiple version of the same module and each team can have his own set of modules without the approbation of other team (one virtualenv by team).
But it seems that packrat are made to be use by a unique user (user must have write permission on packrat directory), and that really killing it. I wrote some R lines to reproduce packrat logic and place the R session in the packrat without touch it (modify .libPath and some environment variables). It works pretty well and all my users can use the same packrat without breaking it (they are only allow to read it). But, from my point of view, it's stupid to redevelop some packrat features in another module. I also have the possibility to use operator::: to use some internal stuff of packrat but if you modify it, I'm screwed up. So I modified packrat source code to allow user to use it without the write permission. I added an option to the "on" methods: "read.only" to specify that you don't want to touch the packrat.
This functionality it's really useful. I made a packrat builder service with Gitlab continuous integration that build all packrat.lock present in a git repo to make it available on R servers for all users (in read only). The advantage of the builder is its use of cache, I saved a lot of space with this little feature. All packrats are made of symlink (storage is problematic for me) and if a user wants to modify the packrat, they copy it in their home and they can use it as before.
I still have to maintain another module for specific purpose (handle multiple packrats, list them and how to switch between them easily) but can I have a chance to see that feature add to packrat ? (My implementation is not necessarily the best but it's simple).