On Wed, Sep 19, 2018 at 10:14 AM, Tzu-ping Chung <uranu...@gmail.com> wrote: > I feel the plan is quite solid. This however leaves us (who want a Python > implementation and interface to do what pip does) in an interesting place. > So I can tell there are a couple of principles: > > 1. Do not use pip internals > 2. pip won’t be using either distlib or setuptools, so they might not match > what pip does, in the long run > > Does this leaves us only one option left, to implement a library that > matches what pip does (follows the standards), but is not pip? That feels > quite counter-productive to me, but if it’s what things would be, I’d accept > it. > > The next step (for me) in that case would then be to start working on that > library.
From what Donald said, the first step is to standardize some chunk of functionality into a PEP (for functionality that doesn't already have a PEP). If you start the library before standardizing via a PEP, it seems like you're just going to exacerbate the problem by creating yet another library with its own implementation variations, introduce new compatibility problems for the future, etc. And a PEP will still need to be created later, anyways. For cases where a PEP already exists, I would also encourage you to add to the library only as you are having pip start to use it. Otherwise, there won't be an easy way to cut pip over to using it, without risking major breakage. This process would also help ensure the implementation matches pip's behavior. --Chris > Since existing behaviours in setuptools and pip (including the part > it uses distlib for) are likely to be standardised, I can rely on distlib > for script creation, setuptools for some miscellaneous things (editable > installs?), and pull (or reimplement) parts out of pip for others. Are there > caveats I should look out? > > TP > > -- > Tzu-ping Chung (@uranusjr) > uranu...@gmail.com > Sent from my iPhone > > On 20 Sep 2018, at 00:39, Donald Stufft <don...@stufft.io> wrote: > > > On Sep 19, 2018, at 5:17 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > > > What is the current situation regarding distlib vs packaging and various > pieces in pip? Many parts of distlib seems to have duplicates in either > packaging or pip/setuptools internals. I understand this is a historical > artifact, but what is the plan going forward, and what strategy, if any, > should a person take if they are to make the attempt of merging, or > collecting pieces from existing code bases into a workable library? > > > Note: This is my personal view of the history only, Vinay and Donald > would be better able to give definitive answers > > > I’ve personally always planned on pulling out the last bits of what we do > use distlib for in pip, and not relying on it any longer. > > My general plan for extracting stuff from pip and/or setuptools has always > been to first standardize in a PEP (if a sufficient one doesn’t already > exist) anything that makes sense to be as a standard, and then start either > reimplementing or pulling code out of pip (or setuptools if pip is using > setuptools). When doing that I had always planned on spending a lot of > effort ensuring that the behavior matches what pip is already doing (or have > known, specific divergences). > > Now some of this already exists in distlib, but I don’t plan on using it. > Part of that is because I find it easier to identify things that should be > standardized but aren’t if I’m not using a big bundle of already implemented > stuff already (for instance, script support needs to be standardized, but it > didn’t occur to us at the time because we just used what distlib had). It > also has a bunch of functionality that exists only in distlib, like > attempting to use JSON to find packages (at one point there was even a > locator that implicitly used a non PyPI server, no idea if there still is) > that I felt made it harder to use the library in a way that didn’t basically > create a new set of implementation defined semantics. It also copied APIs > and semantics that I think *shouldn’t* have been (for instance, it has an > implicitly caching resource API like setuptools does… a generally bad idea > IMO, whereas using the new importlib.resources is a much saner API). > > So in general, there are things that currently only exist in distlib or > setuptools, but my personal long term plan for pip is that we should get > solid implementations of those things out of those libraries, but generally > my mind puts distlib and setuptools in largely the same boat. > > > -- > 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/A42FTYI2Y3TEMEJK7VW25DBVLEAPYYYE/ > -- 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/IGWA344MHEFTLZXSFZQKNO27CUJ2KRFR/
