> 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/2DTOA7EA4ZSL5442G33TVCMCNP7ZNGGS/
