<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 19, 2013, at 11:20 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">Which is an argument, in my mind, to vendor setuptools over bundling (assuming people are using "bundling" as in "install setuptools next to pip or at least install a .pth file to access the vendored version"). Including pip with Python installers is blessing it as the installer, but if we include setuptools as well that would also be blessing setuptools as *the* building tool as well. If people's preference for virtualenv over venv simply because they didn't want to install pip manually has shown us anything is that the lazy path is the used path.</span></blockquote></div><br><div>I don't believe we want to bless setuptools in the long run hence why I want to vendor setuptools under pip.vendor.*.</div><div><br></div><div>I believe pkg_resources should be split out and pip should just dynamically add it to the dependencies for anything that uses entry points. For it's own uses it should not generate scripts that depend on anything that isn't included with pip itself.</div><div>
<br>-----------------<br>Donald Stufft<br>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
</div>
<br></body></html>