Re: Distlib vs Packaging (Was: disable building wheel for a package)

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