[Distutils] PEP 439 and pip bootstrap updated
ncoghlan at gmail.com
Sat Jul 13 08:28:42 CEST 2013
On 13 July 2013 05:25, Brett Cannon <brett at python.org> wrote:
> On Fri, Jul 12, 2013 at 2:16 PM, Donald Stufft <donald at stufft.io> wrote:
>> On Jul 12, 2013, at 2:00 PM, Brett Cannon <brett at python.org> wrote:
>> Speaking with my python-dev hat on which has a badge from when I led the
>> stdlib cleanup for Python 3, I would say anything that has a PEP should
>> probably have a module in the stdlib for it. That way standard management
>> of whatever is specified in the PEP will be uniform and expected to be
>> maintained and work. Beyond that code will exist outside the stdlib.
>> This is basically the exact opposite of what Nick has said the intent has
>> been (Ecosystem first).
> Not at all as no module will go in immediately until after a PEP has
> landed and been vetted as needed.
>> Adding packaging tools beyond bootstrapping pip at this point in the game
>> is IMO a huge mistake. If what Nick has said and PEPs are not appropriate
>> for things that don't have a module in the standard lib well that's fine I
> You misunderstand what I mean. I'm just saying that *if* anything were to
> go into the stdlib it would only be to have code which implements a PEP in
> the stdlib to prevent everyone from re-implementing a standard.
What Brett is saying is closer to what I was thinking when we were
discussing this at the language summit. However, I'm no longer sure distlib
will be quite baked enough to suggest bundling it in 3.4, in which case it
will only be a "pip install distlib" away (that's the entire point of PEP
> I just won't worry about trying to write PEPs :)
> No, the PEPs are important to prevent version skew and make sure everyone
> is on the same page. And that's also what a module in the stdlib would do;
> make sure everyone is on the same page in terms of semantics by using a
> single code base.
> I mean I wouldn't expect anything more than maybe code parsing the JSON
> metadata that does some validation and parsing version numbers that can
> support comparisons and verifying platform requirements; that's it. Stuff
> that every installation tool will need to do in order to follow the PEPs
> properly. And it wouldn't go in until everyone was very happy with the PEPs
> and ready to commit to code enshrining it in the stdlib. Otherwise I hope
> distlib moves into PyPA and everyone who develops installation tools, etc.
> uses that library.
Vinay already moved both distlib and pylauncher over to the PyPA account on
PEP 439 is the critical piece, since that's the one that takes the pressure
off getting the other components (including distlib and pkg_resources) into
the base installers.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG