What stable API would be worth maintaining in pip for others to use? "[Distutils] Announcement: Pip 10 is coming, and will move all internal APIs" https://groups.google.com/forum/m/#!topic/pypa-dev/JVTfS6ZdAuM
On Monday, August 20, 2018, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > 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? Label ideas? - 'stable-api' - Who is offering to maintain a stable API in/with/for pip and the Python community ad infinitum? > Thanks, > --Chris > > > > On Mon, Aug 20, 2018 at 12:51 AM, Dan Ryan <d...@danryan.co> wrote: > > 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. What is the URL of this library of which you are speaking? > > > > 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. An issue label and something like a PEP would likely survive the ravages of 10 years of tools tooling around with community packaging commitments. > > > > Dan Ryan // pipenv maintainer > > gh: @techalchemy > > > >> On Aug 20, 2018, at 2:41 AM, Chris Jerdonek <chris.jerdo...@gmail.com> > 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-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/ > 2QECNWSHNEW7UBB24M2K5BISYJY7GMZF/ > -- > 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/ > 2AYIJ3KTB2QJRF3BGV446DXAJGCFVQ5R/ >
-- 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/PKHH5VQVHOVQGDXRJJBR3GW7XEBBZXXT/
