Equivalent of UV_PROJECT_ENVIRONMENT on uv.toml

[carlosjourdan]

Summary

Current Behavior

Afaik, the virtual environment path can only be configured via the UV_PROJECT_ENVIRONMENT environment variable.

Proposed Enhancement

Add support for configuring the virtual environment path in uv.toml and/or pyproject.toml configuration files.

Example configuration:

[tool.uv]
project-environment= "/path/to/venv"

Use Case & Motivation

• Working in a Citrix/VDI environment where the users home dir is actually a network drive under the hood
• Need to store virtualenvs on local disk for performance reasons
• Supporting "citizen developers" who need a simple setup process:
  1. git clone
  2. uv sync

[zanieb]

I don't think we want to support this in the pyproject.toml, because then a project can cause a sync to an arbitrary location on your machine. This is a "user" setting, not a "project" setting — if that makes sense?

[zanieb]

I think #1495 is a better fit for this use-case

[carlosjourdan]

I get the distinction between "user" and "project" settings in typical development environments.

However, in VDI (and I suspect many other corporate environments), there are often strict controls on where users can write files. This makes the ability to sync to an aribtrary, pre-determined location a helpful feature rather than a problem.

#1495 would be a more elegant solution to this problem, but I hoped supporting the already existing environment variable through the toml configuration might be a simpler interim approach.

[elonzh]

Our Python environment depends on conda components, such as specific versions of OpenSSL, the compilation toolchain, etc. Therefore, we create environments using conda and handle this situation by specifying UV_PROJECT_ENVIRONMENT and UV_PYTHON. However, this is very inconvenient in daily development because these environment variables need to be set every time.

We have tried using pixi, but it is not suitable for us. Compared to uv, it lacks many features; for example, it does not support relative path dependencies, it can only build conda packages, and its dependency resolution prioritizes conda packages over PyPI packages.

Since we must work on the Windows platform, using tools like direnv to set environment variables is also not feasible.

We hope for a local, per-project implementation solution that only requires configuration once.