uv: Flag to allow `uv pip install` to install into specific environments (that do not necessarily contain uv)

I’m planning to work on this next week. I’ll post here with a concrete proposal once I’ve had time to internalize the comments. (Probably something like a --python flag alongside a --system flag but TBD.)

@fruch there’s also now a new --system flag which handles what you need, I think.

sharing one use case of using --prefix and --root,

inside a multi stages docker build, one stage is building/collecting all packages and install them into a /build directory and other stages just copy the content out of into their /usr/local folder.

meanwhile I’ve worked around using those pip flags, by VIRTUAL_ENV=/user/local, and copy all of /user/local between the layers.

This is the exact use case I also have

sharing one use case of using --prefix and --root,

inside a multi stages docker build, one stage is building/collecting all packages and install them into a /build directory and other stages just copy the content out of into their /usr/local folder.

meanwhile I’ve worked around using those pip flags, by VIRTUAL_ENV=/user/local, and copy all of /user/local between the layers.

pip uses --prefix and --python (I think the difference relates to which Python pip should be run with, which doesn’t matter to uv).

A few things:

1. The --python flag is desirable here because the tool that creates an environment is not necessarily the same program that uses an environment (perhaps in IDE). In this case, there is no knowledge of the base Python that was used and therefore no way to get information about its version, architecture, etc. It’s not true to say that pip uses the flag to decide where to run (it’s Python so it’s already running) but rather it’s entirely about information gathering.

   There is no way to avoid invoking the interpreter to get that data until PEP 739 is accepted (and implemented by various tools) and then another of the same kind for virtual environments is accepted (and implemented by various tools).

2. The VIRTUAL_ENV workaround indeed does not work well for base installations because the directory structure is not guaranteed and is often different based on the platform. For example, on Windows installations usually have a python.exe at the root whereas a virtual environment will have that under the Scripts directory. That command doesn’t work in the official Python Docker image for instance:

   ❯ docker run --rm python:3.12 python -c "import sys; print(sys.prefix)"
   /usr/local