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
Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies was significantly more
painful to work with than I had expected.
Accordingly, I'm making some adjustments to the way dependencies are
defined to bring them more into line with the way the contributors
field and contact metadata works:
1. The "*_may_require" fields are all going away (leaving only the
2. The "*_requires" fields are becoming lists of "dependency
specifier" mappings rather than strings
3. A dependency specifier is now a mapping with the following fields:
* "install": the installation specifier for the dependency
* "extra": as per the current PEP (for conditional dependencies)
* "environment": as per the current PEP (for conditional dependencies)
4. The "install" subfield is compulsory, the other two are optional
(as now, using either of the latter creates a "conditional
dependency", while dependency declarations with only the "install"
subfield are unconditional)
5. An installation specifier is what PEP 426 currently calls a
dependency specifier: the "name [extras] (constraints)" format. They
will get their own top level section (similar to the existing Extras
and Environment markers sections)
In addition to those changes, I'll also be making a change to the
recommended handling of virtual distributions (again based on Donald's
feedback): integration tools should NEVER look at the "Provides"
listings on a public index server to satisfy unmet dependencies.
Instead, virtual distributions should be defined in such a way that
whoever first invents the specific virtual distribution name registers
it on PyPI, using the dependency metadata to pull in a default
implementation. That's the only way to manage virtual distributions on
a public index server that isn't vulnerable to later hijacking simply
by registering a distribution with that name.
As part of documenting that, I'll probably give the notion of "Virtual
distributions" their own top level section (these are distributions
that don't have any code of their own - they just declare dependencies
on other projects to make them easy to install as a group, or to
define the default provider for a dependency that may be satisfied by
any one of multiple distributions).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Here's my file layout:
|- enum /
|- test /
__init__ and test_enum are both smart enough to pull in the correct code when imported. The issue I am having is this:
ethan@hydra:~$ sudo easy_install enum34
[sudo] password for ethan:
Searching for enum34
Best match: enum34 0.9
Running enum34-0.9/setup.py -q bdist_egg --dist-dir /tmp/easy_install-sB55B5/enum34-0.9/egg-dist-tmp-qUYAv5
SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/py3_enum.py', 211, 43, ' def __call__(cls, value,
names=None, *, module=None, type=None):\n'))
SyntaxError: ('invalid syntax', ('build/bdist.linux-x86_64/egg/enum/test/py3_test_enum.py', 630, 47, ' class
zip_safe flag not set; analyzing archive contents...
SyntaxError: ('invalid syntax', ('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/py3_enum.py', 211,
43, ' def __call__(cls, value, names=None, *, module=None, type=None):\n'))
SyntaxError: ('invalid syntax',
('/usr/local/lib/python2.7/dist-packages/enum34-0.9-py2.7.egg/enum/test/py3_test_enum.py', 630, 47, ' class
Adding enum34 0.9 to easy-install.pth file
Processing dependencies for enum34
Finished processing dependencies for enum34
distutils is trying to load the py3 versions, which of course fails on a py2 install. The package installs successfully
anyway, but if I were a user I would be wondering if the install was trustworthy.
It seems to me that I need to either have distutils only install the version appropriate files, or to not try to scan
the version inappropriate files, but at this point I do not know how to do either.
Any pointers would be greatly appreciated.
Download counts have (kind of) been re-enabled on PyPI.
The new download counts work as so:
* At the bottom of a detail page there is rolling tallies for the last
day, the last week, and the last month
* The API exposes total download counts per file still.
* The rolling counts update more or less in real time while the total counts in the API update hourly.
* We no longer incorporate download counts from mirrors, making the mirroring infrastructure a tree and not a federation.
 Only the last day is enabled currently, once more data is available the last week and last month will also be enabled.
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Installation instructions for setuptools, eg. here, mention
setuptools 0.8 as a download from pypi. However, pypi doesn't seem to
carry version 0.8, only up to 0.7.4. Are the installation
instructions still work-in-progress, and is 0.7.4 the recommended
Thanks for the clarification,
All the examples of explicit prefix matching in PEP 440 show only release
clause components, but it's not explicitly stated whether that's
specifically intended. For example, are prefix matching clauses such as