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
I'm wondering what the state of play is with the following branches:
What more needs to happen for these to get merged to trunk and a release
This seems odd...
PS D:\Data\PyPI> D:\Data\cpython\PCbuild\python -m packaging.run install nose
installing third-party projects from an uninstalled Python is not supported
And yet after downloading the nose source...
PS D:\Data\PyPI> bsdtar xzf D:\Downloads\Python\nose-1.1.2.tar.gz
PS D:\Data\PyPI> cd .\nose-1.1.2
PS D:\Data\PyPI\nose-1.1.2> D:\Data\cpython\PCbuild\python -m
Installing from source directory: 'D:\\Data\\PyPI\\nose-1.1.2'
Extracting in c:\users\gustav\appdata\local\temp\tmpecso_w
Now working in c:\users\gustav\appdata\local\temp\tmpecso_w\distribute-0.6.14
Building a Distribute egg in D:\Data\PyPI\nose-1.1.2
warning: no files found matching 'Makefile' under directory 'docs'
warning: no files found matching 'indexsidebar.html' under directory 'docs'
(The build actually failed, but for reasons unrelated to the fact that
it's an uninstalled Python, as far as I can see).
Why not allow installing direct from PyPI?
I hope this is the right list for usage questions on
distutils2/packaging. If not, please point me at the correct list.
I'm looking at how I'd translate existing setup.py configurations into
the new setup.cfg format. One situation I'm not sure how to deal with
is the package_data argument to setup(). This allows me to specify
data files which are to be installed as part of a package. How would I
do this in distutils2/packaging? The resources entry seems like the
intended place, but I don't see how I can specify the destination
without making too many assumptions about precisely where the package
will get installed.
After reading everything was possible to read on setuptools and friends,
I'm a bit confused...
I have the following situation:
suppose that there is a framework composed by many many eggs, which
doesn't change very often.
Then there are N applications using this framework, where every
application is also composed by 2-3 eggs, and everything is run in a
"funny" way (using Envisage).
So at the moment every application fiddles around with the global
easy_install.pth, which is bad and needs to be changed, and I have to
figure out how.
My idea would be to
- have a global pypi-server running on localhost
- every application is in a virtualenv (or buildout environment) and
uses this local pypi-server
I'm doing a few experiments, but already I'm not able to make my virtual
env to fetch from my local pypi-server, what is the magic setting for that?
The other future problems that I still see now are:
1. I have to be able to develop also the eggs from the framework
2. I have to make everything very simple to do from and Eclipse
3. These applications have to be shared on SVN, so maybe zc.buildout
might be a better choice in this sense.
Thanks a lot,
Hi, I have a quick question regarding easy_install and MacPorts. I
tried easy_installing nose while using MacPorts (Python 2.6.7 /
py26-distribute @0.6.24_0 / MacPorts version 2.0.3) --
> sudo python -m easy_install nose
This worked, except it installed the nosetests script into--
but did not create an alias in--
So nosetests is not automatically in the path. Was this a problem
with MacPorts, easy_install, or nose? Whose responsibility was it to
create the alias?
Thanks a lot,
while lurking on this lists for quite some month, I'm still wondering
about the status of all the different distutils tools, including
setuptool, pkg_resources, pip, ...). To my impression, there are some
efforts around, but I'm missing some kind of overview or strategy.
Beside the forest of tools, it seams to me, as if the distribution
format is not "stable": pip seams to prefer archives over eggs.
Is there some PEP describing the status and future of Python packaging?
Schönen Gruß - Regards
Dipl.-Informatiker (univ.), CISSP, CSSLP
Spezialist für IT-Sicherheit in komplexen Umgebungen
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult ist Mitglied bei http://www.7-it.de
Hi, I have one more question for the time being. This regards how the
easy_install script works.
I use Mac OSX, and my /usr/bin directory contains three versions of
the easy_install script: easy_install, easy_install-2.5, and
Based on some debugging lines I tried inserting, when I execute the
script called simply "easy_install", the script seems to execute just
the first line (namely "#!/usr/bin/python"), and then seems to
immediately jump to executing easy_install-2.6.
I was curious about the mechanism that allows the Python interpreter
to jump mysteriously from one file to another. This doesn't seem to
be evident from the easy_install scripts themselves. What causes this