Distutils-SIG April 2000

distutils-sig@python.org

23 participants
69 discussions

Revisiting the "pkginfo" patch
by Greg Ward 21 Apr '00

21 Apr '00

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!

2 2

RE: New code snapshot
by Lyle Johnson 20 Apr '00

20 Apr '00

> 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.

2 1

Re: Patch for msvccompiler.py (Win32)
by Lyle Johnson 19 Apr '00

19 Apr '00

> 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 ;)

1 0

MANIFEST.in format
by A.M. Kuchling 18 Apr '00

18 Apr '00

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

3 2

New code snapshot
by Greg Ward 18 Apr '00

18 Apr '00

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 ...

1 0

distutils+numpy problem on AIX
by Greg Ward 18 Apr '00

18 Apr '00

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.

1 0

problem with installing NumPy under WinNT
by Greg Ward 18 Apr '00

18 Apr '00

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.

1 0

Case mismatch error? (was: problem when installing under WinNT)
by Greg Ward 18 Apr '00

18 Apr '00

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.

1 0

examples/sample3 (was: Bug in distutils 0.8)
by Greg Ward 18 Apr '00

18 Apr '00

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?

1 0

Re: Patch for msvccompiler.py (Win32)
by Greg Ward 18 Apr '00

18 Apr '00

[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.

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG April 2000