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.

[1]: https://lwn.net/Articles/757354/ <https://lwn.net/Articles/757354/>


TP


> On 14/9, 2018, at 15:15, Alex Becker <alcubec...@gmail.com> wrote:
> 
> As part of a package management tool <https://github.com/alexbecker/dotlock>, 
> 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.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://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/

--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://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/CXHKLJNDV5OV5ZFMYZSHZR5V6CEY37Z7/

Reply via email to