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
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?
Tim Docker timd(a)macquarie.com.au
Quantative Applications Division
qad16:qad $ ls -l lib/python/
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
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
In the lxml project (http://codespeak.net/lxml), we've just noticed the
following problem with lxml eggs: you can easy_install an egg that won't
work for your Python.
This is because Python can be compiled with either 2 or 4 bytes unicode
as its internal representation. Any egg that contains compiled C code
that uses unicode such as lxml will run into trouble: if it's compiled
with a 4 bytes unicode Python, it won't work on a 2 bytes unicode
Python, and vice versa.
This problem is fairly common in Linux. Many distributions such as
Ubuntu and Fedora compile their python with 4 bytes unicode internal
representation. If you compile a Python interpreter by hand it defaults
to 2 bytes unicode, however. Hand-building a Python interpreter is done
fairly commonly by Linux sysadmins for various reasons.
It would therefore be very nice if it became possible to make eggs for
the different unicode compilation options of Python. This configuration
dimension is a real world issue for any binary Python module that does
anything with unicode text..
In an earlier mail to this list:
M.-A. Lemburg and Phillip Eby had the following discussion:
>>Please make sure that your eggs catch all possible
>>Python binary build dimensions:
>>* Python version
>>* Python Unicode variant (UCS2, UCS4)
>>* OS name
>>* OS version
>>* Platform architecture (e.g. 32-bit vs. 64-bit)
>As far as I know, all of this except the Unicode variant is captured in
>distutils' get_platform(). And if it's not, it should be, since it
>affects any other kind of bdist mechanism.
I'm not sure whether this means this needs to be escalated from
setuptools to the Python interpreter level itself. With this mail, I've
done the job escalating this lxml problem to what appears to be the
right place, though. :)
Firstly, I would like to say thanks for the setuptools package, which
I was introduced to after reading about the RuleDispatch package on
the IBM developerworks charming python series. Oh btw. RuleDispatch is
the most useful python package that I have seen in the last year in
the python world, so thanks for that also ;)
Now that the congrats and hugs are out of the way, I would like to ask
a question. How can I tell setuptools not to put packages, such as
dispatch, protocols, and setuptools, in a subdirectory named the same
as the egg and to just put the package name.
For example from pydoc I currently get:
what I would like to see is just:
Maybe it is just a pet-peeve, but I like to keep a nice tidy
site-packages directory, and these long directory names just seem to
me to be pollution of my site-packages directory in my command shell.
If there is an option to have just the packages, I would really
appreciate someone telling me what it is. If not maybe it could be
considered, and to put whatever meta-data the directory names are
providing somewhere else..
At 08:56 AM 8/31/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>>Would you mind including the entire log of the error, too? Thanks.
>robin-hbl% easy_install svn://kid-templating.org/trunk
>Doing subversion checkout from svn://kid-templating.org/trunk to
>Running setup.py -q bdist_egg --dist-dir
>The required version of setuptools (>=0.6a11) is not available, and
>can't be installed while this script is running. Please install
>a more recent version first.
Ah, the plot thickens. This error message only occurs if there is a
version *conflict* error - that is, you have an installed version of
setuptools on your sys.path that is a lower version than 0.6a11. This
could happen if your default installation location is later on sys.path
than the installation location for an older version of setuptools.
>>> import pkg_resources
>>> print list(pkg_resources.working_set)
And send me the output. I'm guessing it will show a version of setuptools
that's less than 0.6a11, and the path shown with it will be different than
the one you've been installing later versions of setuptools to.
(Oh, and also check which Python version is being run by your easy_install
script, to make sure you run the same version to do the above.)
At 10:46 AM 8/31/2006 +0100, Hamish Lawson wrote:
>Others on the Kid mailing list seem to be having setuptools problems:
>Is it Kid's installation setup that's awry?
That problem is due to them using a11 after I killed off all the alpha
releases from the Cheeseshop to keep people from installing versions that
had some rather serious bugs that were fixed by the beta versions. This
doesn't affect your problem; even though they've changed the ez_setup
you're still going to get an installation conflict error in your
installation. The problem you're having is specific to your installation,
in other words.
On the whole, I think ez_setup is going to have to grow a way to bootstrap
to the "latest non-alpha version" if there's one out there. I should
probably also have it output information about the conflicting setuptools
installation if there's a conflict, as that would have made your problem
easier for you to spot up front.
>Distutils-SIG maillist - Distutils-SIG(a)python.org
At 08:14 PM 8/30/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>>Well, try "easy_install -U setuptools"; it's possible your current
>>installation isn't actually 0.6c1.
>Searching for setuptools
>Best match: setuptools 0.6c1
>setuptools 0.6c1 is already the active version in easy-install.pth
>Installing easy_install script to /usr/local/python/bin
>Installing easy_install-2.4 script to /usr/local/python/bin
>Processing dependencies for setuptools
>But stil the same error after.
Would you mind including the entire log of the error, too? Thanks.
At 08:05 PM 8/30/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>>No idea; it works fine for me. Does "easy_install --help" work?
Well, try "easy_install -U setuptools"; it's possible your current
installation isn't actually 0.6c1. (If you're on Windows, use "ez_setup.py
-U setuptools" instead).
At 07:01 PM 8/30/2006 +0100, Hamish Lawson wrote:
>I have version 0.6c1 of setuptools installed, but when I try to
>easy_install Kid from subversion:
> easy_install svn://kid-templating.org/trunk
>I get this error message:
> The required version of setuptools (>=0.6a11) is not available
>Any pointers to why?
No idea; it works fine for me. Does "easy_install --help" work?