I am confused. If you’re installing things with subprocess, and is using virtual environments anyway, wouldn’t it be simpler to use the pip inside the virtual environment directly?
Instead of using a (random) pip to install into the environment, you can instead do
[virtualenv-path]/[script-prefix]/python -m pip install …
The script prefix would be bin in most cases, or Scripts on Windows. You can dig into the source of venv or virtualenv to find the exact logic and use it, but in practice it is basically enough to test both locations until you find the correct Python executable. (This is also Pipenv’s approach, essentially.)
I wouldn’t say it’s crazy to pip-install into a foreign virtual environment, but can’t recommend it either. pip does a lot of runtime detection when choosing an artifact to install a package. So unless you’re installing directly from URL, there is no guarantee you are installing the correct artifact for a given package, or even choosing the correct version (when you lock the requirements). Pipenv actually used a similar approach in its initial design, but found it to be very error-prone. Reading the project description, however, it seems like you’re locking “specific distributions” for a given package, so I guess this this is not necessarily a problem? I am not sure how you can choose the correct distribution/artifact without using the in-environment pip though (I didn’t read the implementation).
Finally, if all you really want is to download/unpack/install the locked artifact to use, maybe you can even do away with virtual environments altogether. There was a discussion around ditching virtual environments altogether in favour of a node/npm-like setup at this year’s PyCon (I didn’t attend)[1] that you might find interesting.
TP
As part of a
package management tool, I'm trying to use pip to install python packages into a virtualenv, from python code (via subprocess), into a different virtualenv than the virtualenv my python process is running in (if any). I have this *mostly* working with:
pip install --prefix [virtualenv-path] --ignore-installed --no-build-isolation
However, installed scripts break because the scrips automatically get prepended with a shebang pointing to the python interpreter pip was run under.
Is there a way around this behavior? Am I crazy to even try to install into a different virtualenv? Or do I have to re-architect my code to call pip in the target virtualenv (which may require me forcing pip to be installed, depending on what versions of python I choose to support)?
Sincerely,
Alex Becker
--
Distutils-SIG mailing list --
distutils-sig@python.orgTo unsubscribe send an email to
distutils-sig-leave@python.orghttps://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/C5Y2KKW2YQGFE74LZXQLXE32RJOABVEE/