Hi all --
I've finally finished a minor Distutils side-project, which was making
the Distutils 0.1.x codebase run under Python 1.5.1. That's done now,
and I've just released the result as Distutils 0.1.4.
Note that this release has all the brain-damage and limitations, and
most of the bugs, of Distutils 0.1.3. The *real* changes that have been
happening since January are only available as a code snapshot or as part
of Python 1.6 alpha1. I aim to remedy this by putting together a
Distutils 0.9 release Real Soon Now; the idea is that the 0.9 series
will progress towards 1.0 as the Python 1.6 alpha/beta series progresses
towards Python 1.6 final. I make no promises to make one Distutils
release for every Python alpha or beta, though!
The benefit of doing things this way is that developers will be able to
release module distributions that rely on "modern" Distutils, ie. the
0.9 series that is pretty close to what will be in Python 1.6 final.
Hopefully reliance on Distutils 0.1.x will be a thing of the past by the
time Python 1.6 final is out. (Since there are only two incompatible
changes in writing setup scripts between 0.1.x and 0.9.x, I don't think
this will be a huge problem.)
Now, I have to worry about folding my 1.5.1 compatibility hacks into the
current Distutils codebase... sigh... why do I get myself into these
If I use distutils to install a package, and one of the previously
installed files is readonly in
copying build/lib.linux-i586/Perp/util/NumUtil.py ->
error: /usr/lib/python1.5/site-packages/Perp/util/NumUtil.py: Permission
I'd prefer that distutils acts like the BSD "install" command. install
can set readonly permissions on the "target", but will remove the file
to replace it.
And come to think of it, I think that distutils should default to
installing .py and .so files as
National Center for Atmospheric Research
Those of you keeping on top of the Distutils CVS tree might want to do
an update and make sure everything's still working: I've just split to
overly large modules up into smaller files. I've put in temporary "from
... import *" hacks to ensure backwards compatibility for now, but will
take those away once I'm sure I haven't broken anything else. Give it a
Greg Ward - Linux nerd gward(a)python.net
Never put off till tomorrow what you can avoid all together.
Hi all --
I've just updated the credits list in the Distutils README, based on
scanning the CVS logs (ouch). Let me know if you should be on here --
it's only recently that I've been careful about recording contributors'
names in the checkin message, so a few people may have slipped through.
This is in roughly chronological order; to get on this list, you have to
have sent in a patch that I accepted more-or-less verbatim:
* Fred Drake: the sysconfig module
* Amos Latteier: NT support in sysconfig
* Perry Stoll: the MSVCCompiler class and the example setup
script for Numerical Python,
* Robin Becker: registry support in msvccompiler.py
* Thomas Heller: more work on the registry support, several
bug fixes in the Windows support, and just generally improving
the code for compiling extensions on Windows
* Eric Tiedemann: bug fixes
* Fred Drake and Guido van Rossum: helping to figure out the
"right way" to install third-party Python modules
* Joe Van Andel: tweaks to the sysconfig module, misc. bug fixes
* Corran Webster: Mac OS support in general
* Bastian Kleineidam: the "clean" command, and a pile of
patches and bug-fixes, large and small
If you think someone in this list is undeserving of recognition, perhaps
you'd better take it up with them directly. ;-)
Probably should have a list of bug-spotters, but oh well. Maybe
Greg Ward - Linux weenie gward(a)python.net
I repeat myself when under stress I repeat myself when under stress I repeat---
aorry for the delay responding....
> BTW, Is anyone in the NumPy community keeping on top of Distutils?
i know that Paul Dubois feels very strongly about supporting
Distutils. In fact, its now the only way to build the module on its
and i see Joe Van Andel posts regularly to distutils (this is my first
time stopping by) and he is a regular on Numeric as well.
> There have been a *lot* of changes since 0.1.3 was released in
> January, and I have been rather free with making incompatible
> changes (because there's no way I'm gonna be able to get away with
> them after Python 1.6/Distutils 1.0 are out). I've also been
> keeping my examples/numpy_setup.py script up-to-date with the
> changes, in hopes that some eager NumPy hacker will keep an eye on
> the changes in Distutils and be ready to update NumPy's real setup
> script when the time comes.
what do you mean 'real setup script'? i think distutils is it now.
anyway. i'll try to track the latest distutils for you as i stay with
the cvs builds of numpy.
I've just read Guido's description on new features in Python1.6,
including his description of distutils
I'm a bit confused by the description of distutils, since it describes
software that I haven't seen yet, even though I've been using
'distutils'. Guido describes a setup of m4 macros to generate a
setup.py, which in turn generates a Makefile. This is a bit different
than building a setup.py, and simply running it to compile and install
Are the distutils Guido's describes a superset of the distutils found on
cvs.python.org/projects/cvsroot? Or have we forked distutils for
National Center for Atmospheric Research
I saw the announcement a few days back about the Distutils CVS tree being
merged back into the Python 1.6 CVS tree. I was wondering if the plans for
(1) it being available as a separate package, and,
(2) compatibility with Python 1.5.2.
I'm still testing against the Distutils-0.1.3 drop, which of course meets
both of the above requirements. But I wasn't sure how to proceed with
regards to looking at the more recent snapshot(s) and/or the CVS version of
Distutils. I am anticipating that *some* of my end-users will not
immediately upgrade to Python 1.6 when it is released, and I don't want to
make that a requirement since the extension code itself (i.e. my stuff)
doesn't require Python 1.6.
I'm trying to port stuff from Win32 to FreeBSD. Distutils is fine with
win32, but can I use it with freebsd? I notice that earlier methods used
a universal makefile and Setup.in and involved a lot of technology ie
libtool etc etc
> I've just read Guido's description on new features in Python1.6,
> including his description of distutils
> I'm a bit confused by the description of distutils, since it describes
> software that I haven't seen yet, even though I've been using
> 'distutils'. Guido describes a setup of m4 macros to generate a
> setup.py, which in turn generates a Makefile. This is a bit different
> than building a setup.py, and simply running it to compile and install
> extension code.
> Are the distutils Guido's describes a superset of the distutils found on
> cvs.python.org/projects/cvsroot? Or have we forked distutils for
> Python 1.6?
I was somewhat medicated when I read this announcement and failed to notice
the date it was posted. Guido was just playing a mean, mean April Fools
prank on us.