On 13 July 2013 01:02, Donald Stufft <donald@stufft.io> wrote:
>> The installer side of things the purist side of me doesn't like adding it to
>> the standard library for all the same reasons but the pragmatic side of me
>> wants it there because it enables fetching the other bits that are needed for
>> "pip install X" to be a reasonable official response to these kind of
>> questions. But I pushed for and still believe that if a prerequisite for
>> doing that involves "locking" in pip or any of it's dependencies by adding
>> them to the standard library then I am vehemently against doing it.
>
> Nobody seems to be suggesting doing that, though.

I was (trying?) to explain that my belief doesn't extend to only distlib here and
instead to the entire toolchain.

(The above quote may not be the best point to comment on, but I wanted to avoid quoting the whole text just to make a general point on this subject)

In my view packaging (specifically install) tools are a bit different from other things, because generally packaging tools with dependencies suck. Look at pip's reliance on setuptools, for example. Managing setuptools with pip is a pain, and bootstrapping pip involves getting setuptools installed without already having pip available.

I'm +1 on having basic infrastructure in the stdlib, because that way people can concentrate on innovating in more important areas of packaging rather than endlessly reinventing basic stuff. The trick is knowing what counts as basic infrastructure. Things I have *regularly* come up against, over a long period of writing little tools:

1. Version parsing and ordering (I usually use distutils.LooseVersion, just because it's available and "close enough" :-()
2. Reading metadata from distributions (not just parsing it, but getting it out of dist-info files or sdists and the like as well)
3. Installing wheels
4. Locating distributions on PyPI or local indexes

At the moment, my choices are to write my own code (usually meaning far more code than the actual functionality I want to write!) require distlib (not good in a tool for building zero-dependency venvs from the ground up, for example) or vendoring in distlib (impractical in a one-file script). Having something in the stdlib (even if it's only able to bootstrap distlib or an alternative) solves all of these issues.

Paul