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. 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) [email protected] Sent from my iPhone > On 20 Sep 2018, at 00:39, Donald Stufft <[email protected]> wrote: > > >>> On Sep 19, 2018, at 5:17 AM, Paul Moore <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/A42FTYI2Y3TEMEJK7VW25DBVLEAPYYYE/
