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
