feat: added venv_location option to specify virtualenv location #785
Conversation
|
This could also be used by power users to have multiple sessions share a single venv. Nicely combines with better logic on venv reuse. :) |
|
Yes, I was thinking the same thing! I've used a similar (not supported) feature in tox in the past. I'll play around with this possible functionality...
|
|
Does this allow arbitrary path traversal? |
Sorry @cjolowicz, I'm not sure what you mean. If you mean can you place environments anywhere, the answer is yes. So you could do the following: @nox.session(venv_location=os.path.expanduser("~/venvs/project-venv"))
def dev(session):
....To place a dev environment at the location "~/venv/project-venv". Just pushed a commit that wraps |
There was an edge case where the user could pass something like `venv_locaiton="~/tmp/venv"`, but this would be place in a directory `$PWD/~/tmp/venv`. So now use `os.path.expanduser(venv_location)` to fix this.
Got rid of venv_location tests that created folder in home directory
nox/registry.py
Outdated
| @@ -55,6 +56,7 @@ def session_decorator( | |||
| name: str | None = None, | |||
| venv_backend: Any | None = None, | |||
| venv_params: Any | None = None, | |||
| venv_location: str | None = None, | |||
There was a problem hiding this comment.
These should support Path too, I think.
There was a problem hiding this comment.
Totally agree. Will update to os.PathLike
|
Do we do that anywhere else? Any reason not to let a user make it explicit? |
|
The call to When I was working on this, I resisted the urge to convert string paths to For now, I'll make a change allowing os.PathLike objects for |
The user can pass a string or Path object to set venv_location. Note
that for now, I left in `os.path.expanduser`. This coverts things like
`venv_location="~/path/to/dir"` to `$HOME/path/to/dir` instead of
`$PWD/~/path/to/dir`. If you really want the latter behavior, you can
pass in `Path.cwd().joinpath("~", "path", "to", "dir")`
That is what I meant, thanks. Absolute paths won't be very portable and may be surprising behavior when you run Nox on somebody else's project. Why do you think this should be possible? How does the |
|
Are we concerned about users trying something like |
|
How would this interact with parametrization? I could see it potentially being very useful to allow a parametrized test to reuse the same environment, but some cases that would be bad, especially if Python was parametrized over (the most common one!). Would it make sense to allow |
I'm fine restricting
Combining with the comment from @henryiii, I like the idea of using
Yes, I agree this could be an issue. How about a check like: if (EDIT: I'm not sure there's a general solution to testing for a venv) |
|
Does |
No clue. Is there a general way to test if a directory is venv/virtualenv/conda-env? Sorry, accidentally closed PR. Reopened. |
|
A pyvenv.cfg with a home key is always present in a virtual environment, CPython needs it to build sys.path. It doesn't depend on the tool that creates it or the platform. |
|
That's what I thought, but some of the tests are disabled on Windows looking for it (and virutalenv < 20 didn't add one it seems from comments). |
In this case, should I add a check that, if Just an FYI, using |
* Now raises error if passing directly multiple pythons or parametrize for session with `venv_location` * With `venv_location` set, ignore (and warn) `--extra-python` * Warn that session sets `venv_location`
Yes, I think this is a good safeguard.
Either that or just requiring a relative path. I'm not opposed to relaxing this restriction later if people come up with good use cases.
Yes, I'd prefer this solution, also for sessions with multiple Pythons. Let's see some real world usage of this feature before we add something like templating to it. One approach would be to check this in |
|
The latest commit raises an error if trying to pass multiple pythons to a session with TODO
|
This PR adds the option
venv_locationto specify the location for virtualenv creation and a per session basis, and is a follow up to #753.The use case is quickly defining development environments: