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 06:49 PM 7/3/2006 +0200, Matthias Klose wrote:
>Phillip J. Eby writes:
> > At 10:28 PM 6/9/2006 +0200, Matthias Klose wrote:
> > >Phillip J. Eby writes:
> > > > At 09:51 PM 6/9/2006 +0200, Matthias Klose wrote:
> > > > >Hi,
> > > > >
> > > > >when installing an egg in a system-installed python version, then you
> > > > >do have another python version information in the egg_info directory
> > > > >name (py2.x). Is it possible or advisable to exclude that information
> > > > >from the name? At least I know that I'm installing into
> > > > >/usr/lib/python2.3/site-packages.
> > > >
> > > > I don't understand your question. There is no 'egg_info'
> directory. Are
> > > > you talking about a .egg/EGG-INFO directory or an '.egg-info'
> > >
> > >sorry,
> > >
> > > /usr/lib/python2.3/site-packages/setuptools-0.6b2-py2.3.egg-info
> > >
> > >would it be safe to rename that to
> > >
> > > /usr/lib/python2.3/site-packages/setuptools-0.6b2.egg-info
> > >
> > >without loosing functionality?
> > Yes.
>what about installing the .egg-info directory without version
>information when --single-version-externally-managed is used?
Note that the .pyc files will be built for a specific Python version;
that's why the version number is there. Not including the version number
won't magically make it work with other Python versions.
>Another unrelated thing: Debian is supposed to ship the source code
>for binaries, but it's not included in the package for cli.exe and
>gui.exe. Could you point me to the source code and/or include it in
>the next release?
It's included in the source release, along with all the documentation. The
file you're looking for is 'launcher.c'. Of course, the .exe files aren't
used on non-Windows platforms anyway.
I have a problem (possible bug?) with the search path
version python 2.4.3
located in c:\python
I want to have my modules in a completely separate
i made a test module
now i have a test file in
which needs to load test_module.py
Installing Python Modules /Greg Ward
Python Software Foundation
29 March 2006
The most convenient way is to add a path configuration
file to a directory that's already on Python's path,
usually to the .../site-packages/ directory. Path
configuration files have an extension of .pth, and
each line must contain a single path that will be
appended to sys.path. (Because the new paths are
appended to sys.path, modules in the added directories
will not override standard modules. This means you
can't use this mechanism for installing fixed versions
of standard modules.)
Paths can be absolute or relative, in which case
they're relative to the directory containing the .pth
file. Any directories added to the search path will be
scanned in turn for .pth files
So: I put a file "lib.pth" in ../site-packages/
If I put the full path (f:\dev\python\lib\math) to
test_module in this file, it works
and test_001.py can load the test_module
Now for the problem
If i put only (f:\dev\python\lib) in lib.pth
and I put a file math.pth in this path with a relative
sys.path will only have (f:\dev\python\lib) added to
and test_001.py cannot load the test_module
the "Any directories added to the search path will be
scanned in turn for .pth files"
does not work
what did i do wrong?
hope you can point me the way
and thanks for a great language
Frederik AA de Jonge
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
I'm trying to install the Distutils libarary since it does not included in
my python installation. I run Suse linux. I have python 2.4. I've downloaded
the distutils version 1.0.2 (the latest one). When I run 'python
setup.pyinstall' from the installation directory, I get the following
Traceback (most recent call last):
File "setup.py", line 30, in ?
packages = ['distutils', 'distutils.command'],
File "/home/semantay/Distutils-1.0.2/distutils/core.py", line 101, in
_setup_distribution = dist = klass(attrs)
File "/home/semantay/Distutils-1.0.2/distutils/dist.py", line 130, in
setattr(self, method_name, getattr(self.metadata, method_name))
AttributeError: DistributionMetadata instance has no attribute 'get___doc__'
Please help me.
hey all -
the MyghtyUtils package, version 0.52 on cheeseshop, has this general
MyghtyUtils-0.52/lib/myghtyutils/<other .py files>
however, when you run "python setup.py sdist" on an OS X machine
(interestingly, *not* on a windows machine), the resulting tar/gz
file contains an extra file:
no idea why that is...but this creates problems on windows.
Then, when you go to install this package on a windows machine (*not*
on an OS X or other unixy machine), you get this error:
\archive_util.py", line 192, in unpack_tarfile
tarobj._extract_member(member,dst) # XXX Ugh
File "C:\Python24\lib\tarfile.py", line 1440, in _extract_member
File "C:\Python24\lib\tarfile.py", line 1572, in utime
raise ExtractError, "could not change modification time"
tarfile.ExtractError: could not change modification time
when I go into tarfile.py line 1572 and modify the exception to also
print out the underying error, you get this:
IOError: [Errno 13] Permission Denied: 'MyghtyUtils-0.52\\test\
So the extra "._Container.py" file is the source of the windows issue.
If you want to reproduce, simply check out the latest source of
MyghtyUtils from http://svn.myghty.org/myghtyutils/trunk and run
"setup.py sdist". I havent seen this happen with my other packages.
I have solved the problem by just running the sdist on the windows
machine. but this is pretty strange. any ideas ?
sorry for not replying earlier I have been busy at work.
On 7/14/06, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote:
> On Jul 14, 2006, at 3:35 PM, Jorge Vargas wrote:
> > On 7/11/06, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote:
> > On Jul 11, 2006, at 5:17 PM, Jorge Vargas wrote:
> > > noone cares about this? it's a bug so simple to fix....
> > There's loads of bugs and patches in the python tracker, and only a
> > limited amount of time that people work on python. The patch you
> > mentioned also sounds like a fix for a very limited audience, which
> > could explain why nobody has seriously looked at it yet.
> > the patch is more then a year old and is so simple yet so usefull
> > it will take less then 10 min for someone that has commit access
> I haven't looked at the actual patch yet, just read its description.
> Given its description this patch is not something I would have
> reviewed because it seems to be for a very limited audience and is
> not something I can test without additional work (e.g. installing
If you open the patch it's just adding one flag to gcc
> > Are there systems other then gentoo that don't use gcc and g++ but
> > some seemingly cross-compiling setup?
> > the patch is directed to the unixcompiler so why cross-compile?
> Your example mentions a gcc that is named i686-pc-linux-gnu-gcc,
> which looks like a cross-compiling setup to me, a conventional gcc
> setup just has 'gcc' as the name of the compiler. Which systems
> install gcc as i686-pc-linux-gnu-gcc?
the system is gentoo the reason for ccache is that gentoo is a source based
distro. As for the name it is just how the package system (emerge) calls it,
although it will let you compile for other archs, the defaults are set to
your system at instalation time.
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: /var/tmp/portage/gcc-3.3.6/work/gcc-3.3.6/configure
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --disable-libunwind-exceptions
--disable-multilib --disable-libgcj --enable-languages=c,c++,f77
--enable-shared --enable-threads=posix --enable-__cxa_atexit
Thread model: posix
gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
I have just released version 0.6b4 of setuptools, the last beta release of
setuptools 0.6. Please upgrade and test at your earliest convenience, as I
would like to issue a release candidate version next week.
Changes include numerous bug fixes and tweaks for corner cases in
easy_install processing, mostly discovered by Jim Fulton in the process of
developing his "zc.buildout" tool (a Make-like system that supports simple
installation of complex environments).
In addition, there is now a formally-documented "package index API" that
So, people who wish to create their own "package indexes" for easy_install
can do so, even using static HTML -- even without a web server.
Last, but not least, the ability was added to turn off SVN revision numbers
or dates from the command line, so that you don't have to edit setup.cfg in
order to issue a release.
There are a few outstanding requests that I was *not* able to consider for
0.6 because the required changes would've been too disruptive to
stability. They have been bumped to the 0.7 list to receive further
consideration after 0.6 final is released:
* A request to change the PYTHONPATH resolution order
* A request to allow installed scripts to use -O
* Adding XML-RPC support for PyPI