Add the ability to specify venv location from #1222
Conversation
|
Added updates to the docs. Tried to keep the tone to the philosophy of single managed venv, with a small escape valve for CI tools. |
|
@charliermarsh @mitsuhiko I'd love your opinion on this PR. Should cause no change in anyone's current rye flow but will allow more external tooling and parallelization. I have a few of these lined up once we can get this in. Lmk what you think. Thanks |
…o the location of choice.
|
@charliermarsh @mitsuhiko Reposting. I'd love your opinion on this PR. Should cause no change in anyone's current rye flow but will allow more external tooling and parallelization. I have a few of these lined up once we can get this in. Lmk what you think. Thanks |
|
I already mentioned this before but I'm a strong -1 on this. We should find a way to eliminate all needs that require non co-located virtualenvs. Making this configurable will require a lot lot of complexity in tools that can no longer assume the layout of the project. I already wrote down my thoughts on this a few times. #371. There is also a more recent discussion on there: #1211 I'm going to close this for now. |
|
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 |
…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
Added a --venv option to many of the commands. If specified this will be the location of the venv to use for the given step. If not specified then the current
.venvdefault is respected.