<div><span style="color: rgb(160, 160, 168); ">On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>Sorry, Chris must have meant <a href="http://hg.python.org/distlib/">http://hg.python.org/distlib/</a> . I was</div><div>struggling to imagine a world where that is more visible than something on</div><div>bitbucket.</div></div></blockquote><div><br></div><div>I meant that bringing distlib into <a href="http://hg.python.org/cpython/">http://hg.python.org/cpython/</a> would</div><div>give it more visibility to core devs and others that already keep an</div><div>eye on python-checkins (the mailing list). And I think seeing the</div><div>Sphinx-processed docs integrated and cross-referenced with</div><div><a href="http://docs.python.org/dev/">http://docs.python.org/dev/</a> will help people understand better what</div><div>has been done and how it fits in with the rest of CPython -- which I</div><div>think would be useful to the community. It may also encourage</div><div>involvement (e.g. by being part of the main tracker).</div></div></div></span></blockquote><div>On the other hand it makes contributing to it more annoying since it</div><div>does not have pull requests, unless it was just a mirror. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>In asking about the "plan" for doing this, I was thinking of the</div><div>following remark by Nick:</div><div><br></div><div>On Tue, Feb 19, 2013 at 5:40 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>On Tue, Feb 19, 2013 at 11:23 PM, M.-A. Lemburg <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:</div><blockquote type="cite"><div><div><br></div><div>Hmm, what is distlib and where does it live ?</div></div></blockquote><div><br></div><div>As part of the post-mortem of packaging's removal from Python 3.3,</div><div>several subcomponents were identified as stable and useful. distlib is</div><div>those subcomponents extracted into a separate repository by Vinay</div><div>Sajip.</div><div><br></div><div>It will be proposed as the standard library infrastructure for</div><div>building packaging related tools, while distutils will become purely a</div><div>build system and have nothing to do with installing software directly</div><div>(except perhaps on developer machines).</div></div></blockquote><div><br></div><div>My question was basically whether there was a tentative plan for when</div><div>it (or completed parts of it) will be proposed (e.g. when a certain</div><div>amount of functionality is completed, etc). It's better not to do</div><div>this at the last minute if 3.4 is the plan (as I think was attempted</div><div>with packaging but for 3.3).</div><div><br></div><div>On Tue, Feb 19, 2013 at 6:40 PM, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:</div><blockquote type="cite"><div><div><br></div><div>I keep hearing people say that the stdlib is not important, but I don't</div><div>think</div><div>that is true. There are lots of people who have problems with anything not</div><div>in</div><div>the standard library.</div><div><br></div><div>- Beginners often have difficulty (due to inexperience, lack of confidence</div><div>or</div><div> knowledge) in *finding*, let alone installing and using, packages that</div><div>aren't</div><div> in the standard library.</div><div><br></div><div>- To people in the Linux world, adding anything outside of your distro's</div><div> packaging system is a nuisance. No matter how easy your packaging library</div><div> makes it, you now have two sorts of packages: first-class packages that</div><div> your distro will automatically update for you, and second-class ones that</div><div> aren't.</div><div><br></div><div>- People working in restrictive corporate systems often have to jump through</div><div> flaming hoops before installing software.</div></div></blockquote><div><br></div><div>I would also add that for people new to writing Python modules and</div><div>that want to distribute them, it's hard to evaluate what they are</div><div>"supposed" to use (distutils, setuptools, distribute, bento, etc).</div><div>Just a day or two ago, this exact question was asked on the Distutils</div><div>mailing list with subject "Confusion of a hobby programmer." Code not</div><div>being in the standard library creates an extra mental hurdle to</div><div>overcome.</div></div></div></span></blockquote><div>I agree that eventually the stdlib needs standard tooling to work with the future (™) but</div><div>until that future is in use adding it to the stdlib feels premature to me. </div><div><br>
</div>