<p dir="ltr">The pkg_resources script entry point is there so the right eggs can be added to sys.path based on solving dependencies for the invoked package.</p>
<p dir="ltr">On Mar 10, 2013 7:30 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 10 March 2013 00:15, Vinay Sajip <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
> > Paul Moore <p.f.moore <at> <a href="http://gmail.com">gmail.com</a>> writes:<br>
> ><br>
> >> Would it be worth considering splitting distlib into two separate<br>
> >> parts - one that is intended solely for writers of installers and<br>
> >> similar tools, and another for "runtime support" functions that end<br>
> >> users would use? It may not be a practical thing to achieve, but it<br>
> >> would be worth at least understanding the trade-offs involved.<br>
> ><br>
> > While this could be done, it would not exactly be elegant, and IMO it would be<br>
> > the wrong way to address the valid concerns you mention. It would make more<br>
> > sense for pip to *contain* a specific version of distlib for its use (e.g. as a<br>
> > .zip) so that it never worries about conflicts with another copy. This is the<br>
> > approach that Django takes and it seems to work reasonably well for that<br>
> > project.<br>
><br>
> Thanks for the comments. It looks like pip will indeed contain a copy<br>
> of distlib, at least for now. And I think you're right, that is the<br>
> best solution there.<br>
><br>
> My other interest was with regard to virtualenv. Here, the particular<br>
> "runtime support" issue that bothers me is the way that setuptools<br>
> wrapper scripts use entry points. As a result, something like<br>
> nosetests.exe will not work without setuptools being present, simply<br>
> because it looks up the code to run using the entry point mechanisms<br>
> (the actual code itself does not need setuptools). So virtualenv<br>
> pretty much *has* to preinstall setuptools (or at least<br>
> pkg_resources), as pip uses exe-wrappers, and those won't use an<br>
> embedded copy.<br>
><br>
> But looking at the code generated by distlib's script wrappers, I see<br>
> that it does not use the exports functionality of distlib, and as a<br>
> result distlib-generated wrappers can be used without distlib being<br>
> present. So my apologies here - it looks like my concern was<br>
> unfounded.<br>
><br>
> Paul.<br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>