Mailman 3 October 2003 - Distutils-SIG

Preparation of a pure python package for the Windows installer
by Colin J. Williams 30 Oct '03

30 Oct '03

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 below. If I enter this line: C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py sdist the expected zip file is produced. in C:\Program Files\Python23\Lib\site-packages\PyMatrix\dist Colin W. ------------------------------------------------------------------------ C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py bdist_wininst running bdist_wininst running build installing to build\bdist.win32\wininst running install_data creating build creating build\bdist.win32 creating build\bdist.win32\wininst creating build\bdist.win32\wininst\DATA creating build\bdist.win32\wininst\DATA\Docs error: can't copy 'copy.html': doesn't exist or not a regular file C:\Program Files\Python23\Lib\site-packages\PyMatrix>

2 1

Testing the Distutils
by amk＠amk.ca 29 Oct '03

29 Oct '03

I've created a Wiki page for collecting ideas about a Distutils test suite at http://www.python.org/cgi-bin/moinmoin/DistutilsTesting . Please edit it with your own suggestions and ideas. --amk

1 0

Changes in RPM affecting Distutils
by Fred L. Drake, Jr. 28 Oct '03

28 Oct '03

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 -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

4 9

RE: [Distutils] Timeframe of 2.0 again?
by Moore, Paul 28 Oct '03

28 Oct '03

From: M.-A. Lemburg [mailto:mal@lemburg.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 given Python). >> 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 setup.py scripts. 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, Paul.

2 1

Timeframe of 2.0 again?
by Mark W. Alexander 28 Oct '03

28 Oct '03

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 age...) mwa -- Mark W. Alexander slash(a)dotnetslash.net

9 18

RE: [Distutils] Timeframe of 2.0 again?
by Moore, Paul 27 Oct '03

27 Oct '03

From: M.-A. Lemburg [mailto:mal@lemburg.com] > 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 with 2.4? [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 :-) Paul

2 1

CWD when running compilers
by amk＠amk.ca 27 Oct '03

27 Oct '03

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? --amk

2 1

RE: [Distutils] Timeframe of 2.0 again?
by Moore, Paul 27 Oct '03

27 Oct '03

From: Anthony Baxter [mailto:anthony@interlink.com.au] >>> "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? Paul.

3 2

chicken and egg?
by gfa2c 26 Oct '03

26 Oct '03

Hello distutils-sig, 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? Thanks! -- gianfranco accardo gfa2c gmx.net @

4 3

darwin Python 2.1 problem
by Robin Becker 25 Oct '03

25 Oct '03

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 >error: > >creating build/lib.darwin-6.8-Power Macintosh-2.1 >gcc -flat_namespace -bundle -undefined suppress >build/temp.darwin-6.8-Power Macintosh-2.1/_renderPM.o >-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. -- Robin Becker

2 2