On Monday, August 20, 2018, Paul Moore <p.f.mo...@gmail.com> wrote: > On Mon, 20 Aug 2018 at 10:54, Wes Turner <wes.tur...@gmail.com> wrote: > > > > What stable API would be worth maintaining in pip for others to use? > > That's probably the sort of question that can only be usefully > answered by projects like pipenv identifying the functionality they > need and proposing something. Which is of course one of the reasons we > (the pip devs) advise against "just using pip's internals", because it > means we never get that information in any useful form. > > > Who is offering to maintain a stable API in/with/for pip and the Python > community ad infinitum? > > That's the crux of the problem - basically the answer is "no-one". > What we advocate is for generally useful functionality to be split out > into standalone libraries, and then pip, as well as other consumers, > can use those libraries. We already have that with the packaging > library and the script wrappers (part of distlib). The new resolver is > being developed as a standalone library (zazo) as is the PEP 517 hook > wrapper functionality (pep517). There's no reason this model couldn't > work in other areas. (But even then, the question "who's offering to > write these libraries" still applies :-()
Thanks! > > >> > 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? > > I know "security by obscurity" doesn't work, but I'm happier if > details of this library *aren't* widely known - it's not something I'd > want to encourage people using, nor is it supported by pip, as it's > basically a direct interface into pip's internal functions, papering > over the name changes that we did in pip 10 specifically to dissuade > people from doing this. If someone was committing to identifying useful API methods, parameters, and return values; writing a ~PEP; implementing said API; and maintaining backwards compatible shims for some reason; would something like `pip.api` be an appropriate namespace? (now that we're on version 18 with a faster release cycle)? > > Paul >
-- 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/HTD4EF5WIQHMOZAJU4POMA6TI3WSEUMO/
