Custom location for venv #1211
Comments
|
Taking a fork to add this feature, will see if it causes any issues. Will work on it here https://github.com/nazq/rye_venvs |
|
I have a first cut up there which needs some work (mainly tests but a little clean up on ownership, and no docs updated yet). Is there anyone in here who can take a look? Maybe @charliermarsh ? Thanks all, and keep up the great work. |
|
I see a few issues here, I'll probably fix in the am. I need to instruct uv to use the right venv in all cases |
|
Put this PR in for review. #1222 |
|
If we can get this in next thing I plan on doing is putting in a PR for nox to support Rye as a first class tool. I found there is some support for tox but this change may make that easier too. |
|
Not being configurable is by design to push for standardization as far as i can tell: |
Indeed. I see that clearly in the docs. The PR I put in hues to that philosophy and does not change the default workflow in any way. What it does is give build tools which need it an escape hatch. IMO it just makes rye more powerful for users as it improves the build/test ecosystem |
|
What is the exact need for why you need to place the venv elsewhere? That is not entirely clear from your description here. It seems to me to be motivated by other reasons than what has been discussed in #371 before. |
Didn't spot this response, so I'll cross post from the PR discussion. Thanks for responding @mitsuhiko , much appreciated. I've currently moved some 90ish percent of all my projects over to rye and the experience is great. Rye + uv were the build tool change python (py/rust) has been waiting for. Now before we dismiss this I think it's worth exploring it a little further. In general I don't even think about the venv any more when using rye but I do have some edgier cases which make the PR here appealing. One common case I have is mixed rust python builds or simply python builds which need to target multiple python versions. The single .venv makes it difficult to parallelise large build/test runs. I'm more than willing to add this functionality into other OSS tools which would then leverage rye and hopefully make it even more broadly used than today. The PR here should have zero impact on anyone's day to day usage of rye, I was very careful to not change any the current functionality. But it then opens up wider opportunities, Rust brought speed to rye/uv. I think a change like this brings true exogenous parallelism. There are alternatives to a --venv within rye I've played with, for example copying the project around into tmp folders, or even faking out the filesystem so rye still thinks it's using ./.venv but none seem as clean as adding this optional feature to the small number of commands which would need it. I hope you reconsider, I think rye (and uv) have opened the universe of beaten down py developers to what could be. It would be great to expand on that without impacting any users. Let me know your thoughts |
Since learning about rye, I've been using only rye except when it's unavoidable. For example, polars assumes that the contributor is using .venv in the parent folder(not root folder), Support for custom venvs would be nice, but not necessary. |
I've just now checked out #371 . |
I think this is a stronger argument. That said, For parallelization moving the venv will not be sufficient I believe. The reason is that the Python build process pokes around in the build folder too and there is no locking. Checking the code out a second time in another folder is not an option for you I presume? I think I would be open to an environment variable to temporarily rebind the |
…ONMENT` (#6834) Allows configuration of the (currently hard-coded) path to the virtual environment in projects using the `UV_PROJECT_ENVIRONMENT` environment variable. If empty, we'll ignore it. If a relative path, it will be resolved relative to the workspace root. If an absolute path, we'll use that. This feature targets use in Docker images and CI. The variable is intended to be set once in an isolated system and used for all uv operations. We do not expose a CLI option or configuration file setting — we may pursue those later but I see them as lower priority. I think a system-level environment variable addresses the most pressing use-cases here. This doesn't special-case the system environment. Which means that you can use this to write to the system Python environment. I would generally strongly recommend against doing so. The insightful comment from @edmorley at #5229 (comment) provides some context on why. More generally, `uv sync` will remove packages from the environment by default. This means that if the system environment contains any packages relevant to the operation of the system (that are not dependencies of your project), `uv sync` will break it. I'd only use this in Docker or CI, if anywhere. Virtual environments have lots of benefits, and it's only [one line to "activate" them](https://docs.astral.sh/uv/guides/integration/docker/#using-the-environment). If you are considering using this feature to use Docker bind mounts for developing in containers, I would highly recommend reading our [Docker container development documentation](https://docs.astral.sh/uv/guides/integration/docker/#developing-in-a-container) first. If the solutions there do not work for you, please open an issue describing your use-case and why. We do not read `VIRTUAL_ENV` and do not have plans to at this time. Reading `VIRTUAL_ENV` is high-risk, because users can easily leave an environment active and use the uv project interface today. Reading `VIRTUAL_ENV` would be a breaking change. Additionally, uv is intentionally moving away from the concept of "active environments" and I don't think syncing to an "active" environment is the right behavior while managing projects. I plan to add a warning if `VIRTUAL_ENV` is set, to avoid confusion in this area (see #6864). This does not directly enable centrally managed virtual environments. If you set `UV_PROJECT_ENVIRONMENT` to an absolute path and use it across multiple projects, they will clobber each other's environments. However, you could use this with something like `direnv` to achieve "centrally managed" environments. I intend to build a prototype of this eventually. See #1495 for more details on this use-case. Lots of discussion about this feature in: - astral-sh/rye#371 - astral-sh/rye#1222 - astral-sh/rye#1211 - #5229 - #6669 - #6612 Follow-ups: - #6835 - #6864 - Document this in the project concept documentation (can probably re-use some of this post) Closes #6669 Closes #5229 Closes #6612
I've been using rye for a while now and generally very happy with it over poetry. One thing I would like to see though is a general use param to specify the location of the venv. uv has some support for this, at least on venv creation. My thinking was to add an optional param to each of [sync, lock, run] (possibly a few of the others too) which would take the location of the venv, and if not specified keep using the current behaviour of
.venvWith this we'd be able to make tools like nox, and tox work well. I'm also looking at building some parallel build and testing tools which would take advantage of this functionality.
Thoughts?
The text was updated successfully, but these errors were encountered: