I get the impression from the documentation that it should be possible
to use distutils to distribute a pure Python package in a form
acceptable by the Windows installer.
Is this correct?
If so, I would appreciate advice on where I've gone astray in the script
If I enter this line:
the expected zip file is produced. in
C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py
installing to build\bdist.win32\wininst
error: can't copy 'copy.html': doesn't exist or not a regular file
I just tried building an RPM using the bdist_rpm command to setup.py,
and the rpm process complained. Appearantly newer versions of rpm use
a separate build process, rpmbuild, and don't provide sufficient
command line compatibility by default.
I'm using rpm 4.2 on a RedHat 9 system.
Has anyone looked into fixing this in Distutils yet?
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
From: M.-A. Lemburg [mailto:email@example.com]
>> [I'm wondering - is the thing I'm missing that you're using a
>> single shared distutils with all of the Python versions? I
>> can't see how that would work...]
> As I said before, we are using distutils CVS for all Python
> versions we support.
But I assume you install CVS distutils for all the Pythons, and
therefore *could* (but see below) install different versions
(and by implication freeze the distutils version used with a
>> Or are you worried about setup.py not working with both the old
>> and new distutils? That's a valid issue, but I'd assume that
>> the new distutils would have to be careful not to break
>> compatibility with old setup.py files.
> Right. We are adding many features to distutils which we
> need for supporting features like, e.g. automatic configuration,
> etc. These features rely heavily on subclassing and the
> way distutils is tied together. Supporting the more than
> 5 versions out there is not feasable in this kind of setup
> which is typical of distutils packaging, since distutils
> is designed to be extended in this way.
OK, so you are talking about compatibility at the setup.py level.
In that case, I agree entirely - whatever changes are made to
distutils should be done very carefully to avoid breaking existing
Having said that, it would be nice if the distutils documentation
was complete enough that it was feasible to say "we reserve the
right to break anything that isn't documented". In many ways,
that should be the number 1 priority for distutils, complete
documentation of the API.
I'd imagine that there is a nasty grey area where seriously complex
setup.py scripts will need to be deemed as "getting too chummy with
the internals", and breakage will be necessary. Maybe there's a
need for a staged approach (lots more documentation, plus some
official deprecation - for example, things like fancy_getopt - in
2.4, with the API cleanup being left to 2.5).
Thanks for clarifying,
What was the time frame for Distutils2 again? I recall it being
mentioned as "Python 2.4", been when is _that_ targeted.
(I'm trying to expedite being able to sign a contributor agreement in
time to get bdist_pkgtool and bdist_sdux submitted before the next ice
Mark W. Alexander
From: M.-A. Lemburg [mailto:firstname.lastname@example.org]
> Not so: in that case we'd have to keep in sync with at
> least 5 different versions of distutils deployed out there.
I'm sure I am missing something, so please forgive me if I'm
labouring the obvious, but can't you retain all your current
build environments (Python 1.5.2, 2.0, 2.1, 2.2, 2.3) and when
2.4 comes out just add that, and only use the new distutils
[I'm wondering - is the thing I'm missing that you're using a
single shared distutils with all of the Python versions? I
can't see how that would work...]
Or are you worried about setup.py not working with both the old
and new distutils? That's a valid issue, but I'd assume that
the new distutils would have to be careful not to break
compatibility with old setup.py files.
Once again, apologies if I'm being dense. My experience of
distributing Python modules is nothing compared to yours, and
I don't mean to imply that I think your concerns are invalid.
I'm just interested in understanding the issue I've missed, so
that I don't fall into the trap of assuming things are simpler
than they really are :-)
I've come across a situation that may be a Distutils bug, but I'm unsure
if it's a bug or not.
When Distutils runs a compiler subprocess, the current working directory is
left alone so, in the absence of os.chdir() calls in the setup.py, it's the
same directory as the setup.py script. If the source file is in a
subdirectory (e.g. src/constants.c), the CWD is therefore different from the
directory containing the source file.
In C you can use relative #include paths, e.g. #include
<../../hydra/mbv_sched/common.h>. If the source file contains such a
relative #include, it's natural to start from the directory containing the
header or the source file; this is wrong, however.
Question: is this a bug in Distutils? Should distutils.spawn change the CWD
to the same directory as the source?
From: Anthony Baxter [mailto:email@example.com]
>>> "M.-A. Lemburg" wrote
> FWIW, eGenix still ships 1.5.2 compatible packages and we use
> the CVS version of distutils to built the binary packages.
I'm probably being dense here, but why don't you use the version
of distutils that came with Python (or for Python versions before
distutils was in the standard library, a fixed distutils version
compatible with that Python version) to build the binary packages?
It may be more complex to keep the build environment set up, but
surely that's a one-off cost to the distributor, rather than a
significant reason for constraining the development of distutils?
I cannot install a Python application
because it needs distutils.
When I try to install distutils
with its setup.py, it ends in error
because something is missing.
I had a look at the doumentation online
and I still don't know how to proceed.
Can you provide a *specific* link?
Also is there a tar.gz for the documentation
with text or html format?
In article <20031025060859.68323.qmail(a)web42002.mail.yahoo.com>, Chris
Leonello <cleonello(a)yahoo.com> writes
>I am trying to build _renderPM.so for use with Python 2.1.3 in a Zope
>2.6.2 installation on a Mac OS X Jaguar (10.2.8). I recieve the following
>creating build/lib.darwin-6.8-Power Macintosh-2.1
>gcc -flat_namespace -bundle -undefined suppress
>-Lbuild/temp.darwin-6.8-Power Macintosh-2.1 -l_renderPM_libart
>-l_renderPM_gt1 -o build/lib.darwin-6.8-Power Macintosh-2.1/_renderPM.so
>ld: archive: build/temp.darwin-6.8-Power
>Macintosh-2.1/lib_renderPM_libart.a has no table of contents, add one with
>ranlib(1) (can't load from it)
>ld: archive: build/temp.darwin-6.8-Power Macintosh-2.1/lib_renderPM_gt1.a
>has no table of contents, add one with ranlib(1) (can't load from it)
>error: command 'gcc' failed with exit status 1
Is there any way to make static library builds do a ranlib? Some Mac
users say there's a problem with 2.1.