[Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0 (original) (raw)

Donald Stufft donald.stufft at gmail.com
Wed Feb 20 08:53:54 CET 2013

On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:

On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth <dholth at gmail.com (mailto:dholth at gmail.com)> wrote: > Sorry, Chris must have meant http://hg.python.org/distlib/ . I was > struggling to imagine a world where that is more visible than something on > bitbucket. >

I meant that bringing distlib into http://hg.python.org/cpython/ would give it more visibility to core devs and others that already keep an eye on python-checkins (the mailing list). And I think seeing the Sphinx-processed docs integrated and cross-referenced with http://docs.python.org/dev/ will help people understand better what has been done and how it fits in with the rest of CPython -- which I think would be useful to the community. It may also encourage involvement (e.g. by being part of the main tracker).

On the other hand it makes contributing to it more annoying since it does not have pull requests, unless it was just a mirror.
In asking about the "plan" for doing this, I was thinking of the following remark by Nick:

On Tue, Feb 19, 2013 at 5:40 AM, Nick Coghlan <ncoghlan at gmail.com (mailto:ncoghlan at gmail.com)> wrote: > On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg <mal at egenix.com (mailto:mal at egenix.com)> wrote: > > > > Hmm, what is distlib and where does it live ? > > As part of the post-mortem of packaging's removal from Python 3.3, > several subcomponents were identified as stable and useful. distlib is > those subcomponents extracted into a separate repository by Vinay > Sajip. > > It will be proposed as the standard library infrastructure for > building packaging related tools, while distutils will become purely a > build system and have nothing to do with installing software directly > (except perhaps on developer machines). >

My question was basically whether there was a tentative plan for when it (or completed parts of it) will be proposed (e.g. when a certain amount of functionality is completed, etc). It's better not to do this at the last minute if 3.4 is the plan (as I think was attempted with packaging but for 3.3). On Tue, Feb 19, 2013 at 6:40 PM, Steven D'Aprano <steve at pearwood.info (mailto:steve at pearwood.info)> wrote: > > I keep hearing people say that the stdlib is not important, but I don't > think > that is true. There are lots of people who have problems with anything not > in > the standard library. > > - Beginners often have difficulty (due to inexperience, lack of confidence > or > knowledge) in finding, let alone installing and using, packages that > aren't > in the standard library. > > - To people in the Linux world, adding anything outside of your distro's > packaging system is a nuisance. No matter how easy your packaging library > makes it, you now have two sorts of packages: first-class packages that > your distro will automatically update for you, and second-class ones that > aren't. > > - People working in restrictive corporate systems often have to jump through > flaming hoops before installing software. > I would also add that for people new to writing Python modules and that want to distribute them, it's hard to evaluate what they are "supposed" to use (distutils, setuptools, distribute, bento, etc). Just a day or two ago, this exact question was asked on the Distutils mailing list with subject "Confusion of a hobby programmer." Code not being in the standard library creates an extra mental hurdle to overcome.

I agree that eventually the stdlib needs standard tooling to work with the future (™) but until that future is in use adding it to the stdlib feels premature to me.

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130220/1d8ac4bc/attachment-0001.html>

More information about the Python-Dev mailing list