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