Hi all --
at long last, I have fixed two problems that a couple people noticed a
* I folded in Amos Latteier's NT patches almost verbatim -- just
changed an `os.path.sep == "/"' to `os.name == "posix"' and added
some comments bitching about the inadequacy of the current library
installation model (I think this is Python's fault, but for now
Distutils is slavishly aping the situation in Python 1.5.x)
* I fixed the problem whereby running "setup.py install" without
doing anything else caused a crash (because 'build' hadn't yet
been run). Now, the 'install' command automatically runs 'build'
before doing anything; to make this bearable, I added a 'have_run'
dictionary to the Distribution class to keep track of which commands
have been run. So now not only are command classes singletons,
but their 'run' method can only be invoked once -- both restrictions
enforced by Distribution.
The code is checked into CVS, or you can download a snapshot at
Hope someone (Amos?) can try the new version under NT. Any takers for
BTW, all parties involved in the Great "Where Do We Install Stuff?"
Debate should take a good, hard look at the 'set_final_options()' method
of the Install class in distutils/install.py; this is where all the
policy decisions about where to install files are made. Currently it
apes the Python 1.5 situation as closely as I could figure it out.
Obviously, this is subject to change -- I just don't know to *what* it
Greg Ward - software developer gward(a)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
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 am trying to install distribute-0.6.25 in a windows 7 machine. I have
python 2.7.3 in 32 bits, although the machine is 64 bits. I installed
the 32 bit python version because I want to install ipython and there
is no 64 bit builds of the Windows installer for ipython.
In any case, upon installing disuitils with
python setup.py install
I get the following error
No such file or directory
Any help will be greatly appeciated. Thanks,
Manuel López Mariscal
Depto. de Oceanografía Física/CICESE
hi, please cc
i want to release some versions to pypi, but hide them from installing
by explicitly marking as pre-release. i want to preserve versions
numbering as 0.1, 0.2 according to semver.org point 4. is that
Hello setuptools developers,
I'm attempting to package the newest setuptools version (1.1.6)
on Solaris 9 and 10. One of the limitations of the Solaris package manager
(the old one, pkgadd/pkgrm), is that it is unable to handle file names with
spaces. Would you mind renaming "script template.py" to something like
I've just published the first draft of the metadata 2.0 spec that
moves all of the fields that aren't part of the core metadata or
potentially needed for dependency resolution out to a separate
"standard metadata extensions" PEP.
I think this makes PEP 426 itself substantially less overwhelming, and
also provides convenient names to refer to the various other subsets
of the metadata. The new PEP defining the standard extensions is PEP
Metadata 2.0: http://www.python.org/dev/peps/pep-0426/
Standard Extensions: http://www.python.org/dev/peps/pep-0459/
You can see the full deltas for PEP 426 and PEP 440 here:
Or slightly more incremental deltas in the BitBucket repo:
With this update, I believe PEP 440 is extremely close to acceptance,
as I have tried to resolve a number of problems Donald noted while
working on Warehouse, as well as the perennial problem of how to deal
with versioning of packages where Linux distro vendors (or other
system integrators) have applied additional patches.
The PEP 440 changes:
- added the "integrator suffix" (essentially an extra release segment,
separated from the upstream version number by "-"). It is effectively
ignored by most of the matching operators, but sorts as a higher
version than the version with no suffix.
- allowed date based versions for most purposes, but still reject them
for the "~=" compatible version operator. The implied comparison
operator for date based versions is ">=".
- clarified that zeroes and leading zeroes are permitted and that they
should be sorted like numbers
- based on discussions with some of the Red Hat security folks, I
tweaked the direct URL references to *always* require a hash in the
URL, even when using HTTPS or SSH.
PEP 426 and PEP 459 are further away from finalisation, but we're
definitely getting closer to something I'm happy with.
The PEP 426 changes:
- many of the fields are gone, having moved to PEP 459 extensions
- this also allowed the notion of "essential dependency metadata"
(with it's own separate filename) to go away
- the extension format changed to require a submapping
- extensions are now versioned (with an implied 1.0 if not specified)
- as with direct URLs in PEP 440, source URLs are now required to contain a hash
PEP 459 overview:
- standard extensions using the "python.*" namespace
- the details, project, exports and commands extensions just lift
several fields out of PEP 426
- the integrator extension is new, and matches the project extension
structure. It allows redistributors like a Linux distro or a Python
vendor to add their own info without overwriting the upstream project
- the new metadata_hooks extension replaces the install hooks design
in earlier drafts of PEP 426. In this new scheme, Twisted, for
example, would define an appropriate export group hook in order to be
told about any new extensions that exported Twisted plugins and take
In this revised metadata model, distributions *will* trigger their own
postinstall metadata hooks, but won't trigger their postuninstall
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
ok, so PEP459 has exports:
and distlib seems to be implementing them.
and "exports" seem to be entry points 2.0.
so theoretically, when PEP426/PEP459 becomes live....
what does that mean for setuptools-based projects? (I understand that we
might not have a clear idea now, but just trying to narrow down the
1) the setuptools "entry_points" keyword (and pkg_resources api) gets
re-implemented to understand PEP459 exports?
2) "entry_points" keeps the old implementation, and possibly tools are
written to handle the old and new metadata?
3) "entry_points" are stranded, and consumers have to rewrite setup.py
files to use some new keyword that understands PEP459
4) something altogether different...
as for why I'm asking, pip itself is considering command extensions, so
it's a direct practical matter for us.