uv

1234b6dc - Allow customizing the project environment path with `UV_PROJECT_ENVIRONMENT` (#6834)

Allow customizing the project environment path with `UV_PROJECT_ENVIRONMENT` (#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 https://github.com/astral-sh/uv/issues/5229#issuecomment-2312702902 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 https://github.com/astral-sh/uv/pull/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: - https://github.com/astral-sh/rye/issues/371 - https://github.com/astral-sh/rye/pull/1222 - https://github.com/astral-sh/rye/issues/1211 - https://github.com/astral-sh/uv/issues/5229 - https://github.com/astral-sh/uv/issues/6669 - https://github.com/astral-sh/uv/issues/6612 Follow-ups: - #6835 - https://github.com/astral-sh/uv/pull/6864 - Document this in the project concept documentation (can probably re-use some of this post) Closes https://github.com/astral-sh/uv/issues/6669 Closes https://github.com/astral-sh/uv/issues/5229 Closes https://github.com/astral-sh/uv/issues/6612