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
As you have have noticed the download counts on PyPI are no longer updating. Originally this was due to an issue with the script that processes these download counts. However I have now removed the download counts from the PyPI webui and their use via the API is considered deprecated.
There are numerous reasons for their removal/deprecation some of which are:
- Technically hard to make work with the new CDN
- The CDN is being donated to the PSF, and the donated tier does not offer any form of log access
- The work around for not having log access would greatly reduce the utility of the CDN
- Highly inaccurate
- A number of things prevent the download counts from being inaccurate, some of which include:
- pip download cache
- Internal or unofficial mirrors
- Packages not hosted on PyPI (for comparisons sake)
- Mirrors or unofficial grab scripts causing inflated counts (Last I looked 25% of the downloads were from a known mirroring script).
- Not particularly useful
- Just because a project has been downloaded a lot doesn't mean it's good
- Similarly just because a project hasn't been downloaded a lot doesn't mean it's bad
In short because it's value is low for various reasons, and the tradeoffs required to make it work are high It has been not an effective use of resources.
The API will continue to return values for it in order to not break scripts, however in the future all these values will be set to 0. The Web UI has been modified to no longer display it.
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
I got some random releasing (1 on 5 or 6 tries) problems since last pypi update.
For example, with collective.ckeditor (3.6.10 tag on github), the sdist upload
will randomly not upload the file without reporting any error on console:
GPG Key FingerPrint: 0x1A1194B7681112AF
Pensez à l’environnement.
N’imprimez ce courriel que si vous en avez vraiment besoin.
A few of us over on the pythonmac list have been hashing out how best
to support binary packages on OS-X. The binary wheel option seems very
However, there is one Mac-specific issue that does not seem to be addressed:
On OS-X, binaries can be "universal" -- what this means is that they
have more than one binary architecture embedded in a single file; the
system selects the right one at run time. Both executables and dynamic
libraries can be universal. In theory, an universal binary can
currently contain up to 4 architectures:
32+64 bit PPC and 32+64bit x86
In practice, 64 bit PPC was never broadly used, and 32bit PPC is
fading fast. Nevertheless, both 32 and 64 Intel systems are pretty
common, and who knows what there may be in the future (you never know
The binary builds of Python served up on the python.org web site have
supported universal builds for years -- currently there are two
options: 32bit PPC+x86 or 32+64bit x86. It's not a single build, as it
turns out it's hard to support both up to date x86_64 and PPC with the
same compiler. In these builds, the configuration is set up so that
distutils will build universal extensions that match the architectures
included in the builds. This makes it pretty easy to build binary
packages, and/or full app distributions (py2app) that are universal as
setuptools' easy_install supports binary eggs, but always choked on
universal builds -- it didn't know how to identify what matched the
system. It would be really nice if future tools could identify and
install the correct binary wheels for universal builds.
I've taken a look at PEP 427, and see this:
E.g. 'linux_x86_64', 'any'.
That looks to me like there is a built-in assumption that a wheel is
either specific to a single architecture, or any -- so no way to
specify that it may have multiple architectures. So I propose that
platform tag allow a list of some sort:
or, I suppose to keep it simple, a single string:
If so, then a binary wheel could be built (and discovered) that
supported multiple architectures.
Then how would an installer ( pip? ) identify the right one? This is a
bit tricky. PEP 425 states:
"The platform tag is simply distutils.util.get_platform() with all
hyphens - and periods . replaced with underscore"
On my system right now, I have 32bitPPC + 32bit i386 universal python,
running on an intel system:
In : distutils.util.get_platform()
So we may want to patch get_platform() to support universal builds -
or add anther function or something -- you may sometimes what to know
what you are running right now, and other times want to know how the
current python is built. (note that while distutils can build
universal binaries, it's not very smart about it -- all is does is
grab the compiler and linker flags from the Makefile, which include
multiple "-arch" flags.
Even if there is an easy way to query the system, that leaves the
question of what to do. If a user wants to intall a package into a
universal python, will the installer only accept a binary wheel with
all the supported architectures? or one with only the currently
Anyway, it would be nice to be able to get this stuff to "just work"
with universal binaries on the Mac.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I've just uploaded pypiserver 1.1.1 to the python package index.
pypiserver is a minimal PyPI compatible server. It can be used to serve
a set of packages and eggs to easy_install or pip.
pypiserver is easy to install (i.e. just 'pip install pypiserver'). It
doesn't have any external dependencies.
https://pypi.python.org/pypi/pypiserver/ should contain enough
information to easily get you started running your own PyPI server in a
The code is available on github: https://github.com/schmir/pypiserver
Changes in this version
- add 'overwrite' option to allow overwriting existing package
files (default: false)
- show names with hyphens instead of underscores on the "/simple"
- make the standalone version work with jython 2.5.3
- upgrade waitress to 0.8.5 in the standalone version
- workaround broken xmlrpc api on pypi.python.org by using HTTPS