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

uv pip install --directory not working when called with a Python subprocess #10013

Open
djalan opened this issue Dec 18, 2024 · 3 comments
Open
Labels
question Asking for clarification or support

Comments

@djalan
Copy link

djalan commented Dec 18, 2024

Hello

Sample repo? Yes! https://github.com/djalan/uv-pip-install-subprocess

Here is the problem:

As per your documentation @ https://docs.astral.sh/uv/pip/environments/#discovery-of-python-environments

When running a command that mutates an environment such as uv pip sync or uv pip install, uv will search for a virtual environment in the following order:

  • An activated virtual environment based on the VIRTUAL_ENV environment variable.
  • An activated Conda environment based on the CONDA_PREFIX environment variable.
  • A virtual environment at .venv in the current directory, or in the nearest parent directory.

This becomes a problem when you are calling uv using a subprocess.Popen from a Python project that is using a virtual env.

It won't take into consideration the --directory switch and changing cwd current working directory for subprocess.Popen does not resolve the issue.

Using Python 3.11.7 environment at: D:\workspace\project-running-subprocess\.venv
Audited 166 packages in 53ms
print("Install dependencies with 'uv'")
with subprocess.Popen(
    [
        definitions.UV_EXE,
        "pip",
        "install",
        "--directory",
        clone_fullpath.absolute().as_posix(),
        "--no-progress",
        "--color",
        "never",
        "-r",
        requirements_path,
    ],
    stdout=subprocess.PIPE,
    bufsize=1,
    universal_newlines=True,
    cwd=clone_fullpath,
) as proc:
    for line in proc.stdout:
        print(line, end="")

On the other hand, uv venv honors the --directory switch and creates the .venv at the desired location.

print("Create venv with 'uv'")
with subprocess.Popen(
    [
        definitions.UV_EXE,
        "venv",
        "--no-progress",
        "--color",
        "never",
        "--directory",
        clone_fullpath.absolute().as_posix(),
    ],
    stdout=subprocess.PIPE,
    bufsize=1,
    universal_newlines=True,
    cwd=clone_fullpath,
) as proc:
    for line in proc.stdout:
        print(line, end="")

I would fix the problem and amend the documentation and give --directory the biggest priority.

  • The --directory switch on the command line
  • An activated virtual environment based on the VIRTUAL_ENV environment variable.
  • An activated Conda environment based on the CONDA_PREFIX environment variable.
  • A virtual environment at .venv in the current directory, or in the nearest parent directory.
@zanieb
Copy link
Member

zanieb commented Dec 19, 2024

I think you just want uv pip install --python <path-to-venv> instead of using --directory? Changing the working directory via --directory shouldn't change our Python discovery behavior, in my opinion. It should be the same as if you invoked uv from that directory.

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

zanieb commented Dec 19, 2024

(Thank you for all the details and the reproduction!)

@djalan
Copy link
Author

djalan commented Dec 19, 2024

Hello

Your solution works! I pushed it to the repo.

Maybe consider adding [PATH] at the end of uv pip install just like uv venv.
That would replace the --python switch.

Right now it looks like this:

Usage: uv.exe venv [OPTIONS] [PATH]

Usage: uv.exe pip install [OPTIONS] <PACKAGE|--requirements <REQUIREMENTS>|--editable <EDITABLE>>

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

2 participants