Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In case VIRTUAL_ENV is different from .venv UV_PROJECT_ENVIRONMENT should be created automatically #7778

Closed
avoutsas67 opened this issue Sep 29, 2024 · 6 comments
Labels
question Asking for clarification or support

Comments

@avoutsas67
Copy link

Hi all,

If I understand correctly, the current behaviour of uv add when VIRTUAL_ENVIRONMENT is different than .venv is to raise a warning and create a .venv environment where the dependency will be created.
warning: VIRTUAL_ENV=.venv-py312does not match the project environment path.venv and will be ignored Using Python 3.12.6 interpreter at: /opt/homebrew/opt/python@3.12/bin/python3.12 Creating virtualenv at: .venv

I believe it would be more intuitive and more efficient when the VIRTUAL_ENV is different from .venv that the UV_PROJECT_ENVIRONMENT is set automatically to VIRTUAL_ENV by uv init. This will remove an extra step in setting up a project.

If a users wants to use a different environment from the one set in VIRTUAL_ENV then they could explicitly set the UV_PROJECT_ENVIRONMENT.

Thanks for considering this request.

Achilleas

@zanieb
Copy link
Member

zanieb commented Sep 29, 2024

We intentionally don't support using the "active" virtual environment for a project.

More context in #6834 which links to much more discussion.

@sglbl
Copy link

sglbl commented Nov 29, 2024

@zanieb So how can I use my cpu-based-venv without removing the other one?

Image

@adhadse
Copy link

adhadse commented Dec 28, 2024

Unfortunately, this doesn't allow me to keep all virtual environments at one place under ~ dir.

Currently UV_PROJECT_ENVIRONMENT only allow me to configure for one project.

I usually name project environments with the same name as project and keep them under one folder in ~/uv_environments.

@zanieb
Copy link
Member

zanieb commented Dec 28, 2024

@adhadse that's tracked in #1495

@sglbl we don't really support that yet. You can hack it with UV_PROJECT_ENVIRONMENT but there's not a way to define multiple persistent environments. We're thinking about it, but there can be 2^N environments (N = number of groups + extras + resolution modes) for each project and we don't want to just store every combination ever created.

@zanieb zanieb added the question Asking for clarification or support label Dec 28, 2024
@mgu
Copy link

mgu commented Jan 4, 2025

@adhadse for this specific use case, I use direnv and export UV_PROJECT_ENVIRONMENT in my .envrc. I don't know if this is something that could help you

@adhadse
Copy link

adhadse commented Jan 6, 2025

Right now, I'm not interested in fiddling with this issue. I'm going with how uv does it. I'll come back to it later once I start using uv with more and more projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Asking for clarification or support
Projects
None yet
Development

No branches or pull requests

5 participants