Hi --
[cc'd to the distutils-sig, since this turns out to deserve a public
airing rather than being the private email it started out as]
after *waaay* too long, I've finally gotten around to looking at the
"pkginfo" patch to the Distutils you posted back in January. A few
comments:
* I'm not convinced a separate PackageInfo class is needed -- the
Distribution stuff is the home for package meta-data, and if it
gets a bit more complex (eg. dependencies list), I think that's
OK. I definitely don't like having two classes (Distribution
and PackageInfo) with largely the same info, though.
* I'm leery of doing the fancy stuff, namely required packages
and compatible versions. While your data model might well be
the Right Thing, it might not, and I don't think this stuff
has been sufficiently discussed on the SIG. And I'm also
not sure that adding slots for the data without having code
to back them up is right, either. On the one hand, it's good
to get people in the habit of listing requirements/dependencies,
but I don't want to raise false expectations that the Distutils
will actually *do* anything with that information. (It will
someday, but post-Distutils 1.0/Python 1.6.)
* I find your type-checking machinery in pkginfo.py intriguing, but
again I'm not sure if it's appropriate. It's a neat approach to a
common problem, but strikes me as over-engineered for this one
module. If I'm going to do really thorough type-checking on the
attributes of one class, I'd rather do it everywhere.
Anyways, my inclination right now is to take the important stuff from
pkginfo.py -- writing the "package info" file -- and graft it into
install_info.py. I suppose reading the "package info" file will also be
necessary to support an uninstall script. (*Not* an uninstall command,
because you don't want to require having the source distribution around
in order to uninstall something!)
What say you? [And what say other members of the SIG?]
Greg
--
Greg Ward - geek gward(a)ase.com
http://starship.python.net/~gward/
All of life is a blur of Republicans and meat!
> I've just put out another Distutils code snapshot; this fixes all
> problems with Distutils 0.8 that I have heard about. If I don't hear
> anything bad about this snapshot, it'll go out the door as 0.8.1,
> probably tomorrow (Wed April 19) evening.
This snapshot still has the problem for processing MANIFEST.in files under
Windows. This bug was fixed for a while in the CVS sources but seems to have
gotten broken again. If you have a line like this:
include test/autotest.py
in your MANIFEST.in file, running "setup.py sdist" under Windows won't
include this file because the path separator is wrong.
> Sounds like it's not needed for MSVC++, so let's not do it there -- I'm
> still waiting to hear back from Lyle if he figured out why it wasn't
> working for him.
Sorry, Greg, I thought you saw my earlier follow-up message. I am no longer
having a problem needing to add python15.lib to the list of libraries (for
Visual C++). It is correctly (automatically) picked up by the pragmas in the
header file. I have no idea why it wasn't working that day, although user
error is high on the list ;)
Is there a reason the MANIFEST.in file only accepts a single pattern
per line? I'd like to able to write something like this:
recursive-include extensions Makefile.pre.in Setup.in *.c *.h
Would patches for this change be accepted?
--amk
I've just put out another Distutils code snapshot; this fixes all
problems with Distutils 0.8 that I have heard about. If I don't hear
anything bad about this snapshot, it'll go out the door as 0.8.1,
probably tomorrow (Wed April 19) evening.
If you've had problems with 0.8, please download the snapshot and give
it a try:
http://www.python.org/sigs/distutils-sig/download.html#snapshot
Come to think of it, if 0.8 worked for you, or if you haven't tried it
yet, please give the snapshot a whirl.
Thanks --
Greg
--
Greg Ward - nerd gward(a)ase.com
http://starship.python.net/~gward/
I had a lease on an OEDIPUS COMPLEX back in '81 ...
Mike Hammill <mike(a)pdc.kth.se>:
> Does anyone know why I might get the following messages when trying to use
> distutils 0.8 to install NumPy on an AIX machine?
>
> unable to execute ./ld_so_aix: No such file or directory
> error: command './ld_so_aix' failed with exit status 1
This is a "quirk" in how Python's Makefile is installed under AIX. (I
won't call it a bug, since I just skimmed through the Makefile and don't
see a clean way to fix it -- you'd have to install a slightly altered
Makefile with an absolute path for ld_so_aix, which would both be ugly
and break the relocatability of the Python installation.
I think I see how to workaround it in the Distutils, but for now you'll
have to do it yourself. Try this: edit Python's installed Makefile
($exec_prefix/lib/python1.5/config/Makefile; I assume you know your own
exec_prefix!) and change "./ld_so_aix" to "$(LIBPL)/ld_so_aix".
*PLEASE* save a copy of your original Makefile -- this is both for your
own sanity, and so that I can use you as a guinea pig when I have a
Distutils patch to workaround this quirk!
> My goal is to get Python 1.5.2 running with NumPy for the users of our SP at
> the Royal Institute of Technology. I recently downloaded NumPy from LLNL:
> LLNLDistribution11.tgz and
> Numerical-14.tar.gz
Incidentally, this is an old version of Numerical. You should get the
latest release, 15.2, from http://numpy.sourceforge.net/.
Thanks for the failure-to-workaround-Python-quirk report! (OK, OK, it's
a bug report.)
Greg
--
Greg Ward - Linux nerd gward(a)ase.com
http://starship.python.net/~gward/
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
Berthold Hoellmann <hoel(a)germanlloyd.org>:
> I tried to install NumPy under NT using setup_numpy.py from distutils
> 0.8. Compiling failed because Python.h could not be found. I tracked it
> down to the following:
>
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from distutils import sysconfig
> >>> sysconfig.exec_prefix
> '""'
> >>> import sys
> >>> sys.exec_prefix
> 'G:\\bin\\Python'
> >>> sysconfig.EXEC_PREFIX
> '""'
There is a bug in Distutils 0.8 that clobbers (can clobber?)
sysconfig's PREFIX and EXEC_PREFIX globals -- apparently they are
defined in the config.h installed with Python on Windows, and reading
that config.h overwrites those two module globals.
Anyways, it's fixed in the current CVS version. I'll put out a code
snapshot later tonight, and probably release 0.8.1 tomorrow to get the
bugs fixed in a real release. Please try the CVS and/or snapshot and
make sure it really is fixed.
Thanks --
Greg
--
Greg Ward - Linux geek gward(a)ase.com
http://starship.python.net/~gward/
Paranoia is simply an optimistic outlook on life.
Berthold Hoellmann <hoel(a)germanlloyd.org>:
> I've written a package called qpPy, which I would like to install under
> WinNT. But when I import the successfull installed I get:
>
> ...
> NameError: Case mismatch for module name qpPy.py
> ...
>
> Is there any idea how to solve this (besides renaming the file by hand)?
Are you sure this is a Distutils problem? If you copy qpPy.py manually,
do you still get the case mismatch? What *is* the case of the installed
filename, and how are you trying to import it? It would help to show
some state-of-the-filesystem snapshots before and after Distutils
installs the file, and explain why exactly there's a case mismatch
(remember, not all of us use Python on Windows, so not everyone is
necessarily familiar with this case-mismatch problem -- I certainly am
not, so I can only guess about what's going on here).
Greg
--
Greg Ward - Unix bigot gward(a)ase.com
http://starship.python.net/~gward/
Never put off till tomorrow what you can put off till the day after tomorrow.
Berthold Hoellmann <hoel(a)germanlloyd.org>:
> I guess i've found a small bug in distutils 0.8. sample3/setup.py shows
> how to extend the build command. Besides the missing function 'run_peer'
> in the Build class, it tries to load Build from command.build. I guess
> it should import command.build.build instead
Yep, you're quite right. I've fixed the bug and will check it in
shortly. Thanks for spotting this --
Greg
--
Greg Ward - Unix geek gward(a)ase.com
http://starship.python.net/~gward/
I am having FUN... I wonder if it's NET FUN or GROSS FUN?
[me, being a worry-wart]
> It has just occurred to me that those pragmas are awfully
> handy things,
> but can we rely on them?
[Mark Hammond]
> In my experience, we can rely on them more than users specifying the
> correct libraries! Particularly with version changes, and
> debug/release builds. This may or may not be relevant to distutils.
But the whole *point* of the Distutils is that users don't have to worry
about it anymore; now there's just a big system that knows The Right
Thing to do to build extensions on their platform and Python version.
So I don't have any moral objection to adding python15.dll or
python16.dll or whatever to the library search path when building
extensions if needed.
Sounds like it's not needed for MSVC++, so let's not do it there -- I'm
still waiting to hear back from Lyle if he figured out why it wasn't
working for him.
And I still haven't heard from anyone with experience of using GCC or
Borland's compiler to build Pythone extensions. Anyone?
[Mark again]
> If they dont support the pragma (which I bet they will)
Wouldn't surprise me if Borland's compiler did support the library
pragma, but whether GCC does... again, does anyone with direct personal
experience of either compiler *know*?
Greg
--
Greg Ward - just another /P(erl|ython)/ hacker gward(a)ase.com
http://starship.python.net/~gward/
Life is too short for ordinary music.
