Hi all, I've been aware that the distutils sig has been simmerring away, but until recently it has not been directly relevant to what I do. 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. 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. A sample of what the directory looks like is shown below. 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?). So, has this SIG considered such versioning issues yet? Cheers, Tim -------------------------------------------------------------- Tim Docker timd@macquarie.com.au Quantative Applications Division Macquarie Bank -------------------------------------------------------------- qad16:qad $ ls -l lib/python/ total 110 drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1 -r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1 dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8 drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1 dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1 dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3 drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7 dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1 qad16:qad $ ls -l lib/python/1.1 total 30 lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1 lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8 lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1 lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1 lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3 lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7 lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1
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
On Wed, 21 Apr 1999, Greg Ward wrote:
On 19 April 1999, Timothy Docker said:
Assuming it does, then how will this be achieved? I am presently managing this with a messy arrangement of symlinks.
That's about the only thing I can think of.
Symlinks aren't portable. I use a package which imports a subpackage based on code performed in the toplevel __init__.py file. So, for example, my Snow directory (in my sys.path): Snow/ __init__.py mknewversion.py Snow_1999_3_14 Snow_1999_3_16 ... The code in __init__.py is a bit ugly but looks something like: import sys, os, imp, string _dir = __path__[0] _listdir = os.listdir(_dir) _thisdir = os.path.basename(_dir) _instdirs = filter(lambda x: x[:len(_thisdir)+1] == _thisdir+'_', _listd def datesort(f1, f2): parts1 = string.split(f1, '_') parts1[1:] = map(int, parts1[1:]) parts2 = string.split(f2, '_') parts2[1:] = map(int, parts2[1:]) return cmp(parts1, parts2) _instdirs.sort(datesort) _latest = _instdirs[-1] _file, _pathname, _description = imp.find_module(_latest, __path__) _module = imp.load_module(_latest, _file, _pathname, _description) globals().update(_module.__dict__) This is similar to Pmw's scheme. mknewversion.py is a similar-looking script which makes copies of the current version, comes up with the directory name based on the date and existing versions, and does some platform-specific things (add symbolic links for the programmer's sake, not the user's). It's not ideal, but it's portable and customizable. --david
participants (3)
-
David Ascher -
Greg Ward -
Timothy Docker