On 19 April 1999, Timothy Docker said:
I like the look of the proposed api, but have one question. Will this support an installed system that has multiple versions of the same package installed simultaneously? If not, then this would seem to be a significant limitation, especially when dependencies between packages are considered.
That's not something I've thought about, and it didn't come up in the "heated discussion" (not *quite* a flamefest) about version numbers that kicked off this sig back in December. (Although just about everything else relating to software versioning did come up: see http://www.python.org/pipermail/distutils-sig/1998-December/000016.html and ensuing posts for the whole discussion. *Please* don't bring it up again on the mailing list; I'm going to try to put off the continuation of that discussion until I have actual code for dependency checking.)
Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks. A package is installed with its version number in it's name, and a separate directory is created for an application with links from the unversioned package name to the versioned one. Then I just set the pythonpath to this directory.
That's about the only thing I can think of. But that scheme isn't entirely compatible with the library organization I had in mind for the Distutils, ie. installed packages and modules go right under site-packages, rather than having a separate directory for each distribution. (The trouble with this is that you either have to add to your PYTHONPATH for every installed distribution, or have lots of .pth files scattered around. The former is annoying and error-prone, and the latter is a nasty kludge that is neatly avoided by using the site-packages directory.) So your scheme could be made to work for distributions that put all of their modules under a common base package -- Distutils itself, for example, or the XML library. Distributions that use multiple base packages could probably be made to work with some difficulty. But it couldn't handle distributions that don't use the Python package system at all, because modules from those distributions will be dumped straight into site-packages. (Moral: use packages! [unless supporting Python 1.4 is essential for you])
I'm sure there is a better solution that this, and I'm not sure that this would work under windows anyway (does windows have symlinks?).
If there is a better solution, it hasn't occured to me in the five minutes I've been writing this post. Nor do I know if it would work on !Unix. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913