Thanks. Is the state of affairs as you described them what you're
planning for the future as well, or do you anticipate any changes
worthy of note?
Also, are any of the bugs filed in pipenv's tracker due to bugs or
rough spots in pip -- is there a way to find those, like by using a
label? It would be good to be able to know about those so pip can
improve and become more useful. It doesn't seem like any bugs have
been filed in pip's tracker in the past year by any of pipenv's top
contributors. That seems a bit surprising to me given pipenv's heavy
reliance on pip (together with the fact that I know pip has its share
of issues), or is there another way you have of communicating
regarding things that interconnect with pip?
Thanks,
--Chris
On Mon, Aug 20, 2018 at 12:51 AM, Dan Ryan
Sure I can grab that— we patch pip because we use some internals to handle resolution and we have some bugs around that currently. They aren’t upstreamed because they aren’t actually present in pip, only in pipenv. Pipenv crosses back and forth across the virtualenv boundary during the process. Pipenv relies on piptools and vendors a patched version of pip to ensure consistency as well as to provide a few hacks around querying the index. We do have a bit of reimplementation around some kinds of logic, with the largest overlap being in parsing of requirements.
As we handle some resolution, which isn’t really something pip does, there is no cli interface to achieve this. I maintain a library (as of last week) which provides compatibility shims between pip versions 8-current. It is a good idea to use the cli, but we already spend enough resources forking subprocesses into the background that it is a lot more efficient to use the internals, which I track quite closely. The preference toward cli interaction is largely to allow internal api breakage which we don’t mind.
For the most part, we have open channels of communication as necessary. We rely as heavily as we can on pip, packaging, and setuptools to connect the dots, retrieve package info, etc.
Dan Ryan // pipenv maintainer gh: @techalchemy
On Aug 20, 2018, at 2:41 AM, Chris Jerdonek
wrote: Hi,
Can someone explain to me the relationship between pipenv and pip, from the perspective of pipenv's maintainers?
For example, does pipenv currently reimplement anything that pip tries to do, or does it simply call out to pip through the CLI or through its internal API's? Does it have any preferences or future plans in this regard? How about upstreaming to pip fixes or things that would help pipenv?
I've been contributing to pip more lately, and I had a look at pipenv's repository for the first time today. https://github.com/pypa/pipenv
Given that pip's code was recently made internal, I was a bit surprised to see that pipenv vendors and patches pip: https://github.com/pypa/pipenv/tree/master/pipenv/patched/notpip Before I had always assumed that pipenv used pip's CLI (because that's what pip says you should do).
I also noticed that some bugs in pipenv's tracker seem closely related to pip's behavior, but I don't recall seeing any bugs or PR's in pip's tracker reported from pipenv maintainers.
Without knowing a whole lot more than what I've stated, one concern I have is around fragmentation, duplication of work, and repeating mistakes (or introducing new ones) if a lot of work is going into pipenv without coordinating with pip. Is this in any way similar to the beginning of what happened with distutils, setuptools, and distribute that we are still recovering from?
--Chris -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/2...