-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible to "create" renvs at a path other than home directory? #1
Comments
This isn't possible (yet?). Virtual environments are either global, or project-local. Project-local environments will be created with The cache location is configurable with the |
I've added some code to allow for absolute paths to environments, but need to think this through a bit more. In Python, a virtual environment is a directory of 'stuff' -- including a Python binary (usually as a symlink), as well as related utilities. Normally, the intention is that one 'activates' a Python virtual environment by running the Python binary in that virtual environment. In
you're writing the infrastructure to load that environment into the current project, so that the associated environment can be automatically loaded. This is opposed to the Python model, when that infrastructure lives within the virtual environment itself. Just to drive the point home, let's compare the layout for a Python virtual environment:
And for an
With the actual pieces of the virtual environment (the R library) living in The intention is that R sessions launched in the project directory will use the I think one nice thing about the It sounds like users just call |
All that said -- a virtual environment should probably just be a directory; I'm already confusing myself trying to explain the semantics here so it could probably be simplified. |
Ahh I see. Very interesting. I think my desire for arbitrary directories is more a holdover from the Python virtualenv way of doing things, where the naming of the environment is (and probably should be) arbitrary lest there are naming collisions across projects. For instance, I am not a huge fan of Python virtualenv "home directory" behavior where you have to name the environment for storage at the home directory level and naming collisions are possible. I much prefer to name the project at the project level, with some type of state stored at the home directory or some other location for optimization. At very least, I think the exercise of simplifying / explaining the semantics will be valuable, as users will need to work with many of these varied constructs across languages. |
We've decided to eschew the concepts of 'global' vs. 'local' virtual environments. Instead, we just have the Packrat default baseline of a project-local library. |
What code did @kevinushey add?
To point a project to another projects environment locally, I add the line to the ".Rprofile" : |
The conversation in this issue is now outdated -- the way What you're doing is exactly what we would suggest with the current architecture :-) |
I feel like I am seeing some type of weirdness with renvs that are tried with a path.
Created on 2019-01-03 by the reprex package (v0.2.1)
I think this relates to my preferences in
virtualenv
😄Not sure if
renv::init()
is the only way you can get arenv
within a project, and whether any project would ever be justified in having more than onerenv
locally.The other use case to wonder about here is whether you could put
renv
s or the cache at a shared location. This is something that I know some users were interested in for packrat.The text was updated successfully, but these errors were encountered: