On Fri, 14 Sep 2018 at 18:40, Dan Ryan wrote:
> To add to these responses, Tzu Ping and I have tried this in a myriad of
> creative ways and mostly haven’t been successful while relying on pip’s cli.
> The right answer is to invoke the virtualenv pip, it’s just easier
pip can also be
To add to these responses, Tzu Ping and I have tried this in a myriad of
creative ways and mostly haven’t been successful while relying on pip’s cli.
The right answer is to invoke the virtualenv pip, it’s just easier
-D
Dan Ryan // pipenv maintainer
gh: @techalchemy
> On Sep 14, 2018, at
On Fri, 14 Sep 2018 at 08:16, Alex Becker wrote:
> 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
Isn't virtualenv's default behavior to install pip automatically when
a virtualenv is created?
https://virtualenv.pypa.io/en/stable/userguide/#usage
(That is, I don't think you need to "force" pip to be installed, but
rather simply rely on default behavior.)
--Chris
On Fri, Sep 14, 2018 at
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
The main downside to invoking pip in the virtualenv is that it means I have
to have pip installed within the virtualenv, which is something I haven't
wanted to commit to in the interest of creating slim virtualenvs for
bundling with apps. But you are probably right and I need to accept that.
On
Yes, why not simply invoke the pip installed in the virtualenv into
which you want to install the packages? It doesn't seem like you'd
need to "re-architect" anything insomuch as simply change "pip" in
your argument list to the path to the pip inside the virtualenv you're
targeting.
--Chris
On
