<div>
I think the biggest thing missing wrt to command hooks is the ability
</div><div>to have the tool automatically generate a OS specific wrapper (.exe for</div><div>windows, extension less with a shebang for *NIX). While I think it would</div><div>be useful for this feature to live in std lib, I don't think it's near as required</div><div>as getting the core of packaging into stdlib.</div><div><br></div><div>Attempting to create packaging as outside of stdlib brings up images</div><div>of <a href="http://xkcd.com/927/">http://xkcd.com/927/</a>, and to me the only thing prevent packaging</div><div>from just being another standard is the "Blessing" that comes with</div><div>being in stdlib.</div>
<div></div>
<p style="color: #A0A0A8;">On Wednesday, May 16, 2012 at 2:55 AM, Tarek Ziadé wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On 5/16/12 3:58 AM, Chris McDonough wrote:</div><blockquote type="cite"><div><div>Adding two more (packaging and distutils2) which are similarly </div><div>semi-documented and which don't even solve the problems that the </div><div>previous ones do would serve no purpose, and baking them into Python </div><div>itself will mean they can't evolve in important ways.</div></div></blockquote><div><br></div><div>Oh, I think I need to answer to this too since you said you wanted to </div><div>help. Packaging is not intended to be similar to setuptools in its features.</div><div><br></div><div>For instance we won't provide console scripts or entry points. The first </div><div>one because 'script' is the same feature (except there's an indirection </div><div>and I said before we could mimic this)</div><div>The second one because we should build this kind of feature outside the </div><div>stdlib (this is not something most people use, according to the survey I </div><div>did back a few years ago, it's mostly zope/plone/repoze land)</div><div><br></div><div>I'd suggest you list what you can't do with "packaging" today and we </div><div>work through that list to point which features are missing and should be </div><div>developed *outside* the standard lib, and which ones are in "packaging" </div><div>or should be</div><div><br></div><div>IOW: packaging should only be the common basis and provide a basic </div><div>installer - not a full fledge tool you can use to replace the most </div><div>advanced setuptools features. And we want it pluggable enough so people </div><div>can build pluggable features on the top of it, like Eric explained earlier</div><div><br></div><div>Does that make sense ?</div><div><br></div><div>Cheers</div><div>Tarek</div><div><br></div><div>_______________________________________________</div><div>Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>