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
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 04:21 PM 6/29/2006 +0100, Paul Moore wrote:
> File "D:\Apps\Python25\Lib\msilib\__init__.py", line 115, in add_data
> raise MSIError("Could not insert "+repr(values)+" into "+table)
>_msi.MSIError: Could not insert [(None, 'site_packages',
>'TEST-1~1.EGG|test-1.0-py2.5.egg-info', 186L, None, None, 512, 1)]
This line is masking whatever the actual error is. If you look at the
source, you'll see it's doing "except Exception,e:" and trapping whatever
the real problem is. I'd suggest commenting out the try/except and see
what error comes up instead. That should tell us more about the problem.
I believe Martin v. Loewis is the author of bdist_msi; I'm not sure if he
reads this list or not. Perhaps he will comment.
At 04:13 PM 6/29/2006 +0100, Paul Moore wrote:
>Agreed. But in the absence of a standard, supporting package authors'
>existing approaches, which work with other distutils mechanisms, seems
>like a reasonable requirement.
Anything that the package author installs as package data, or using the
data_files option to setup(), is included in the egg. And if you install
unzipped, you should be able to browse the included docs.
At 12:03 AM 6/30/2006 +0200, Jérôme Bouat wrote:
> > only the contents of "/usr/lib/python2.x/config/" -- the directory where
> > Python's build configuration information is copied upon installation.
>Its seems that my Mandriva Linux distro did not package this well:
>[j@localhost ~]$ rpm -q --all | grep --ignore-case python
You might first want to check if there is a 'python-dev' or 'python-devel'
package you can install; some distributions only install the 'config'
directory with such a package.
>[j@localhost ~]$ rpm -q --list $(rpm -q --all | grep --ignore-case
>python) | grep --ignore-case makefile
>[j@localhost ~]$ locate -i makefile | grep --ignore-case python
>[j@localhost ~]$ rpm -q
>Maybe I should report this as a Mandriva bug.
What you've shown above is an unrelated Makefile. It's likely that the
needed 'config' directory is installed by another package that you don't
currently have installed.
If there is no such package, or it doesn't install the 'config' directory,
then you should indeed report a bug.
At 10:39 PM 6/29/2006 +0200, Jérôme Bouat wrote:
>Thanks for your reply.
>Thus, distutils is not designed for distributing a module outside the
>Python source repository ?
I don't understand your question. When Python is installed, it installs a
copy of the Makefile that was used to create that Python installation. So
this has nothing to do with the source directory used to compile Python,
only the contents of "/usr/lib/python2.x/config/" -- the directory where
Python's build configuration information is copied upon installation.
If I do something like:
python2.4 setup.py register bdist_egg upload
as recommended in the setuptools documentation, I end up with 2
"releases" in PyPi. One has all my descriptive information and the
other has the egg. One or more will or won't be hidden according
some rule that I haven't been able to divine. If the release with
the meta data (e.g. description, author, etc.) is not hidden, then
easy_install can't seem to find the eggs. At least this is true
today. I thought it wasn't true yesterday, but I don't trust my
recollection. If I hide the release with the descriptive
information, then easy_install can find the eggs, but most of my meta
data isn't shown. Has anyone else seen this behavior, or am I just
For now, I'm not uploading eggs to PyPI, which is a shame, because
setuptools sure made it convenient. :(
Jim Fulton mailto:firstname.lastname@example.org Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.comhttp://www.zope.org