On Tue, Sep 25, 2018 at 3:21 AM, Nick Coghlan
On Tue, 25 Sep 2018 at 19:48, Chris Jerdonek
wrote: What I'm trying to gauge is, if the plan is for pipenv not to depend on pip, and pipenv has strictly greater functionality than pip, then what purpose will PyPA have in continuing to develop pip in addition to pipenv?
That's not the plan, as all of pip's features for actually installing/uninstalling packages, and for introspecting the *as built* package environment, aren't things where pipenv's needs diverge from pip's.
That's not what Tzu-ping said though. In an earlier email, he said, "If we can’t use pip internals, then yes, the plan is to not depend on pip." --Chris
Where their needs diverge is at the dependency resolver level, as pipenv needs to be able to generate a lock file for an arbitrary target environment that may not match the currently running Python interpreter *without* necessarily installing those packages anywhere (although it may need to build wheels to get the dependency listing), whereas pip has the more concrete task of "get theses packages and their dependencies installed into the currently active environment".
If it helps, think of pipenv relating to pip in much the same way as pip-tools (pip-compile/pip-sync) relates to pip, just with Pipfile and Pipfile.lock instead of requirements.in and requirements.txt.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia