On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth <dho...@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). 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 <ncogh...@gmail.com> wrote: > On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg <m...@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 <st...@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. --Chris _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
