From godzilla@netmeg.net (Les Schaffer) Mon Apr 3 04:17:56 2000 From: godzilla@netmeg.net (Les Schaffer) (Les Schaffer) Date: Sun, 2 Apr 2000 23:17:56 -0400 (EDT) Subject: [Distutils] patch to change order of -I's in build_ext.py Message-ID: <14568.3428.798181.549643@gargle.gargle.HOWL> aorry for the delay responding.... Greg said: > 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 own. 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. les schaffer From vanandel@ucar.edu Mon Apr 3 16:28:07 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Mon, 03 Apr 2000 09:28:07 -0600 Subject: [Distutils] Guido's announcement of distutils Message-ID: <38E8B887.B9867631@atd.ucar.edu> I've just read Guido's description on new features in Python1.6, including his description of distutils http://www.deja.com/=dnc/getdoc.xp?AN=60533012 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? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From jlj@cfd1.cfdrc.com Mon Apr 3 17:38:27 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Mon, 3 Apr 2000 11:38:27 -0500 Subject: [Distutils] RE: Distutils-SIG digest, Vol 1 #195 - 2 msgs In-Reply-To: <20000403160031.135CC1CEAB@dinsdale.python.org> Message-ID: <003701bf9d8b$093582a0$4e574dc0@coltrane.cfdrc.com> > I've just read Guido's description on new features in Python1.6, > including his description of distutils > > http://www.deja.com/=dnc/getdoc.xp?AN=60533012 > > 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. From gward@python.net Tue Apr 4 01:43:58 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 20:43:58 -0400 Subject: [Distutils] FreeBSD In-Reply-To: <38E4DA9F.ABC9A035@atd.ucar.edu>; from Joe Van Andel on Fri, Mar 31, 2000 at 10:04:31AM -0700 References: <38E4DA9F.ABC9A035@atd.ucar.edu> Message-ID: <20000403204358.A522@beelzebub> [Robin Becker] > 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 [Joe Van Andel] > I use distutils on Linux and it works fine for building extensions to > Python. Since distutils uses Python code, and doesn't rely on make or > libtools, I think it should work fine on FreeBSD. > > I don't think distutils is going to replace 'make' for general > development in the immediate future, but it works great for building > Python extensions. Umm, what he said. Hell, I *write* the Distutils on Linux and test them sporadically under Solaris. If anything goes wrong under FreeBSD, then I want to hear about it -- it sounds like FreeBSD is emerging as the third-most-popular Unix system, and is therefore worth worrying about. I have yet to actually use the Distutils under Windows, although that'll probably change soon (sigh) -- I am just a tiny bit stunned that the system actually works for you Windows folks. (And oh yeah, sorry about the Unix-geek user interface... I wanted to get something working this millenium.) (The millenium starts in 2001, remember!) Greg -- Greg Ward - "always the quiet one" gward@python.net http://starship.python.net/~gward/ UFO's are for real: the Air Force doesn't exist. From gward@python.net Tue Apr 4 01:49:27 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 20:49:27 -0400 Subject: [Distutils] Will Distutils-1.0 be available outside of Python 1.6? In-Reply-To: <002301bf9b38$49466fd0$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Fri, Mar 31, 2000 at 11:41:03AM -0600 References: <002301bf9b38$49466fd0$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000403204927.B522@beelzebub> On 31 March 2000, Lyle Johnson said: > 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 > "Distutils-1.0" include: > > (1) it being available as a separate package, and, > (2) compatibility with Python 1.5.2. Yes on both counts. It might even work with Python 1.5.1, but I haven't determined how much more work it'll be to back-port it. (I started a few weeks ago, but got distracted.) The issue that is still to be decided is: how to evolve Distutils in between Python 1.6 and 1.7 in such a way that Python 1.6 users can install it, use it, and not mess with the standard library. Might require renaming the standard lib. distutils directory and letting the site-packages version be what Python finds. > 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. Hmmm, that's a very good argument for me putting out Distutils 0.9 real soon now, and evolving towards 1.0 for the final Python 1.6 release: give people like you (and your users) a chance to get used to the upheaval since 0.1.3. I'll have to take a look at my to-do list and see if the current state of the code justifies calling it 0.9, or if it should be 0.8. Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ I want you to MEMORIZE the collected poems of EDNA ST VINCENT MILLAY ... BACKWARDS!! From gward@python.net Tue Apr 4 01:51:51 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 20:51:51 -0400 Subject: [Distutils] Guido's announcement of distutils In-Reply-To: <38E8B887.B9867631@atd.ucar.edu>; from Joe Van Andel on Mon, Apr 03, 2000 at 09:28:07AM -0600 References: <38E8B887.B9867631@atd.ucar.edu> Message-ID: <20000403205151.C522@beelzebub> On 03 April 2000, Joe Van Andel said: > I've just read Guido's description on new features in Python1.6, > including his description of distutils > > http://www.deja.com/=dnc/getdoc.xp?AN=60533012 > > 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'. *chortle* *guffaw* Don't feel bad, Joe, you weren't the only one who fell for it. Just to clarify: there is only one Distutils, the most recent code (as I write this) is what's included in Python 1.6 alpha 1, the description at www.python.org/sigs/distutils-sig remains valid, and the Distutils that will be included in Python 1.6 final will not be substantially different from what you've all been playing with. tee hee hee... Greg -- Greg Ward - just another Perl hacker gward@python.net ^^^^ an april fool's signature? http://starship.python.net/~gward/ Place your clothes and weapons where you can find them in the dark. From gward@python.net Tue Apr 4 01:53:17 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 20:53:17 -0400 Subject: [Distutils] patch to change order of -I's in build_ext.py In-Reply-To: <14568.3428.798181.549643@gargle.gargle.HOWL>; from Les Schaffer on Sun, Apr 02, 2000 at 11:17:56PM -0400 References: <14568.3428.798181.549643@gargle.gargle.HOWL> Message-ID: <20000403205317.D522@beelzebub> On 02 April 2000, Les Schaffer said: > > 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. "Real setup script" == the setup script distributed with NumPy, as opposed to the example NumPy setup script that I maintain (which tends to be simpler than the real thing, since it's an *example*) > anyway. i'll try to track the latest distutils for you as i stay with > the cvs builds of numpy. Thank you! You're a brave man -- Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ And I wonder ... will Elvis take the place of Jesus in a thousand years? -- Dead Kennedys From gward@python.net Tue Apr 4 03:44:15 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 22:44:15 -0400 Subject: [Distutils] Code reorganization Message-ID: <20000403224415.A940@beelzebub> 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 whirl, please... Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ Never put off till tomorrow what you can avoid all together. From gward@python.net Tue Apr 4 02:19:11 2000 From: gward@python.net (Greg Ward) Date: Mon, 3 Apr 2000 21:19:11 -0400 Subject: [Distutils] Distutils credits list Message-ID: <20000403211911.A655@beelzebub> 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 later... Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ I repeat myself when under stress I repeat myself when under stress I repeat--- From vanandel@ucar.edu Tue Apr 4 23:18:41 2000 From: vanandel@ucar.edu (Joe Van Andel) Date: Tue, 04 Apr 2000 16:18:41 -0600 Subject: [Distutils] installing over read-only files in /usr/lib/python1.5/site-packages Message-ID: <38EA6A41.C85DE6ED@atd.ucar.edu> If I use distutils to install a package, and one of the previously installed files is readonly in /usr/lib/python1.5/site-packages/ distutils prints: copying build/lib.linux-i586/Perp/util/NumUtil.py -> /usr/lib/python1.5/site-packages/Perp/util error: /usr/lib/python1.5/site-packages/Perp/util/NumUtil.py: Permission denied 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 readonly. Reactions? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel@ucar.edu From gward@cnri.reston.va.us Wed Apr 5 02:10:06 2000 From: gward@cnri.reston.va.us (Greg Ward) Date: Tue, 4 Apr 2000 21:10:06 -0400 Subject: [Distutils] Distutils 0.1.4 released Message-ID: <20000404211005.A11674@cnri.reston.va.us> 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 things... Greg From msimcich@accesstools.com Wed Apr 5 15:35:20 2000 From: msimcich@accesstools.com (Michael Simcich) Date: Wed, 5 Apr 2000 07:35:20 -0700 Subject: [Distutils] Installation on Win2K Message-ID: <001e01bf9f0c$2bc15e20$0100a8c0@pinol1.sfba.home.com> This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BF9ED1.7F628620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi there - The distutils readme says this: Obviously, in order to use the Distutils you must first install them. Luckily, since the goal of the whole project is to make distributing and installing Python module distributions painless, this is quite easy: python setup.py install For some of us I guess things just can't be too simple. I untarred the tar file so that there is distutils dir under the python dir. From a command prompt, when in the main distutils dir that contains setup.py, I type "python setup.py install" and get the following: E:\Python\Distutils-0.1.3>python setup.py install 'python' is not recognized as an internal or external command, operable program or batch file. I added python.exe to my path and it didn't help. Thanks for any help! Michael Simcich AccessTools ------=_NextPart_000_001F_01BF9ED1.7F628620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = there=20 -
 
The = distutils readme=20 says this:
 
Obviously, in order=20 to use the Distutils you must first install them.
Luckily, since the = goal of=20 the whole project is to make distributing and
installing Python = module=20 distributions painless, this is quite easy:
 
   =20 python setup.py install
 
For = some of us I=20 guess things just can't be too simple. I untarred the tar file so that = there is=20 distutils dir under the python dir. From a command prompt, when in the = main=20 distutils dir that contains setup.py, I type "python setup.py = install" and=20 get the following:

E:\Python\Distutils-0.1.3>python setup.py install
'python' is = not=20 recognized as an internal or external command, operable program or batch = file.

I=20 added python.exe to my path and it didn't help. Thanks for any=20 help!

Michael Simcich
AccessTools =

 
------=_NextPart_000_001F_01BF9ED1.7F628620-- From calvin@cs.uni-sb.de Wed Apr 5 16:30:29 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed, 5 Apr 2000 17:30:29 +0200 (CEST) Subject: [Distutils] Installation on Win2K In-Reply-To: <001e01bf9f0c$2bc15e20$0100a8c0@pinol1.sfba.home.com> Message-ID: >I added python.exe to my path and it didn't help. Thanks for any help! What do you mean exactly "added to my path"? I assume that you added the directory where python.exe lies into the set PATH statement in your autoexec.bat. In this case you have to reexecute autoexec.bat to set your path with the changed value. After this it should work. If you want to propagate this change system-wide you have to reboot. Bastian Kleineidam From msimcich@accesstools.com Wed Apr 5 17:13:01 2000 From: msimcich@accesstools.com (Michael Simcich) Date: Wed, 5 Apr 2000 09:13:01 -0700 Subject: [Distutils] Installation on Win2K In-Reply-To: Message-ID: <000001bf9f19$d189a1c0$0100a8c0@pinol1.sfba.home.com> Actually I have rebooted. Python.exe is in the path as revealed when I type path it shows up as expected. The error persists. Michael Simcich AccessTools -----Original Message----- From: distutils-sig-admin@python.org [mailto:distutils-sig-admin@python.org]On Behalf Of Bastian Kleineidam Sent: Wednesday, April 05, 2000 8:30 AM To: Michael Simcich Cc: distutils-sig@python.org Subject: Re: [Distutils] Installation on Win2K >I added python.exe to my path and it didn't help. Thanks for any help! What do you mean exactly "added to my path"? I assume that you added the directory where python.exe lies into the set PATH statement in your autoexec.bat. In this case you have to reexecute autoexec.bat to set your path with the changed value. After this it should work. If you want to propagate this change system-wide you have to reboot. Bastian Kleineidam _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig From calvin@cs.uni-sb.de Thu Apr 6 00:59:48 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu, 6 Apr 2000 01:59:48 +0200 (CEST) Subject: [Distutils] Installation on Win2K In-Reply-To: <000001bf9f19$d189a1c0$0100a8c0@pinol1.sfba.home.com> Message-ID: >Actually I have rebooted. Python.exe is in the path as revealed when I type >path it shows up as expected. The error persists. Hmm, ok, another point to pay attention: do not use whitespace in the set PATH=... command. E.g. this is bad: set PATH=c:\windows;c:\program files\python (if python.exe is in c:\program files\python\python.exe) Use this: set PATH=c:\windows;c:\progra~1\python or set PATH=c:\windows;"c:\program files\python" This is known to work on my Win98 system. If this does not work for you, provide a copy of your PATH command. You could even try the Microsoft hotline. Bastian Kleineidam From calvin@cs.uni-sb.de Thu Apr 6 01:01:13 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu, 6 Apr 2000 02:01:13 +0200 (CEST) Subject: [Distutils] Error in -h help option Message-ID: Here is a patch: *** distutils.orig/distutils/dist.py Thu Apr 6 01:50:27 2000 --- distutils.patched/distutils/dist.py Thu Apr 6 01:50:09 2000 *************** *** 185,190 **** --- 185,191 ---- # late import because of mutual dependence between these classes from distutils.cmd import Command + from distutils.core import usage # We have to parse the command line a bit at a time -- global Bastian Kleineidam From msimcich@accesstools.com Thu Apr 6 01:33:02 2000 From: msimcich@accesstools.com (Michael Simcich) Date: Wed, 5 Apr 2000 17:33:02 -0700 Subject: [Distutils] Installation on Win2K In-Reply-To: Message-ID: <000101bf9f5f$aaccef10$0100a8c0@pinol1.sfba.home.com> Thanks. I got it to install, I had included the python.exe in the path. I'm kind of ill, maybe that will serve as an excuse. Thanks for the assist. Michael Simcich AccessTools -----Original Message----- From: Bastian Kleineidam [mailto:calvin@cs.uni-sb.de] Sent: Wednesday, April 05, 2000 5:00 PM To: Michael Simcich Cc: distutils-sig@python.org Subject: RE: [Distutils] Installation on Win2K >Actually I have rebooted. Python.exe is in the path as revealed when I type >path it shows up as expected. The error persists. Hmm, ok, another point to pay attention: do not use whitespace in the set PATH=... command. E.g. this is bad: set PATH=c:\windows;c:\program files\python (if python.exe is in c:\program files\python\python.exe) Use this: set PATH=c:\windows;c:\progra~1\python or set PATH=c:\windows;"c:\program files\python" This is known to work on my Win98 system. If this does not work for you, provide a copy of your PATH command. You could even try the Microsoft hotline. Bastian Kleineidam From gward@python.net Thu Apr 6 02:17:24 2000 From: gward@python.net (Greg Ward) Date: Wed, 5 Apr 2000 21:17:24 -0400 Subject: [Distutils] Installation on Win2K In-Reply-To: <001e01bf9f0c$2bc15e20$0100a8c0@pinol1.sfba.home.com>; from Michael Simcich on Wed, Apr 05, 2000 at 07:35:20AM -0700 References: <001e01bf9f0c$2bc15e20$0100a8c0@pinol1.sfba.home.com> Message-ID: <20000405211724.A615@beelzebub> On 05 April 2000, Michael Simcich said: > "python setup.py install" and get the following: > E:\Python\Distutils-0.1.3>python setup.py install > 'python' is not recognized as an internal or external command, operable > program or batch file. > > I added python.exe to my path and it didn't help. Thanks for any help! What *exactly* do you mean by "added python.exe to [your] path"? You should add *the directory that contains python.exe* to your path. What is the output of the "path" command in the command-prompt window where you're attempting to run Python? (Urgh.. attempting to dredge up long forgotten MS-DOS crud...) Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ Think big -- pollute Lake Superior. From msimcich@accesstools.com Thu Apr 6 06:58:15 2000 From: msimcich@accesstools.com (Michael Simcich) Date: Wed, 5 Apr 2000 22:58:15 -0700 Subject: [Distutils] Installation on Win2K In-Reply-To: <20000405211724.A615@beelzebub> Message-ID: <000401bf9f8d$19b4d5f0$0100a8c0@pinol1.sfba.home.com> Right... that was it... it's just been so long since I messed with paths. Michael Simcich AccessTools -----Original Message----- From: distutils-sig-admin@python.org [mailto:distutils-sig-admin@python.org]On Behalf Of Greg Ward Sent: Wednesday, April 05, 2000 6:17 PM To: distutils-sig@python.org Subject: Re: [Distutils] Installation on Win2K On 05 April 2000, Michael Simcich said: > "python setup.py install" and get the following: > E:\Python\Distutils-0.1.3>python setup.py install > 'python' is not recognized as an internal or external command, operable > program or batch file. > > I added python.exe to my path and it didn't help. Thanks for any help! What *exactly* do you mean by "added python.exe to [your] path"? You should add *the directory that contains python.exe* to your path. What is the output of the "path" command in the command-prompt window where you're attempting to run Python? (Urgh.. attempting to dredge up long forgotten MS-DOS crud...) Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ Think big -- pollute Lake Superior. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://www.python.org/mailman/listinfo/distutils-sig From robin@jessikat.demon.co.uk Thu Apr 6 07:57:27 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Thu, 6 Apr 2000 07:57:27 +0100 Subject: [Distutils] Installation on Win2K In-Reply-To: References: <000001bf9f19$d189a1c0$0100a8c0@pinol1.sfba.home.com> Message-ID: In article , Bastian Kleineidam writes >>Actually I have rebooted. Python.exe is in the path as revealed when I type >>path it shows up as expected. The error persists. >Hmm, ok, another point to pay attention: do not use whitespace in the >set PATH=... command. E.g. this is bad: >set PATH=c:\windows;c:\program files\python >(if python.exe is in c:\program files\python\python.exe) >Use this: >set PATH=c:\windows;c:\progra~1\python >or >set PATH=c:\windows;"c:\program files\python" > >This is known to work on my Win98 system. >If this does not work for you, provide a copy of your PATH command. >You could even try the Microsoft hotline. > >Bastian Kleineidam On my system I have Microsoft Chat, Microsoft FrontPage Express, Microsoft Visual Studio, .... all with spaces in side in directory Program Files. If I want to set up a path programatically to my VC++ files (inside Visual studio) how do I know to use MICROS~1 rather than MICROS~6? -- Robin Becker From skip@mojam.com (Skip Montanaro) Thu Apr 6 19:04:49 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Apr 2000 13:04:49 -0500 Subject: [Distutils] How to actually use distutils? Message-ID: <200004061804.NAA07663@beluga.mojam.com> Now that there is a distutils directory under .../Lib in the Python distribution and Guido is deprecating the soundex extension module, I figure it's time to try wrapping up my soundex-in-Python replacement using Distutils. Only problem is, I see nothing that looks like any documentation for it in the Python source tree. core.py mentions a setup script, but I see no example of such a beast. Perhaps .../Lib/distutils needs a README file, especially if the contents of that directory alone are not sufficient to create a distribution (I sort of suspect they aren't). Pointers appreciated... -- Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ From fdrake@acm.org Thu Apr 6 20:11:44 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 6 Apr 2000 15:11:44 -0400 (EDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <200004061804.NAA07663@beluga.mojam.com> References: <200004061804.NAA07663@beluga.mojam.com> Message-ID: <14572.57712.838828.602826@seahag.cnri.reston.va.us> Skip Montanaro writes: > Distutils. Only problem is, I see nothing that looks like any documentation > for it in the Python source tree. core.py mentions a setup script, but I > see no example of such a beast. Perhaps .../Lib/distutils needs a README There is documentation in the distutils CVS repository, at least skeletal. I'll talk to Greg about just where that should go. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From thomas.heller@ion-tof.com Thu Apr 6 20:19:44 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 6 Apr 2000 21:19:44 +0200 Subject: [Distutils] How to actually use distutils? References: <200004061804.NAA07663@beluga.mojam.com> Message-ID: <02e101bf9ffd$11055e50$4500a8c0@thomasnotebook> > Now that there is a distutils directory under .../Lib in the Python > distribution and Guido is deprecating the soundex extension module, I figure > it's time to try wrapping up my soundex-in-Python replacement using > Distutils. Only problem is, I see nothing that looks like any documentation > for it in the Python source tree. core.py mentions a setup script, but I > see no example of such a beast. Perhaps .../Lib/distutils needs a README > file, especially if the contents of that directory alone are not sufficient > to create a distribution (I sort of suspect they aren't). Try the distutils resource page: http://www.python.org/sigs/distutils-sig/ Regards, Thomas Heller From skip@mojam.com (Skip Montanaro) Thu Apr 6 19:23:11 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Apr 2000 13:23:11 -0500 (CDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <14572.57712.838828.602826@seahag.cnri.reston.va.us> References: <200004061804.NAA07663@beluga.mojam.com> <14572.57712.838828.602826@seahag.cnri.reston.va.us> Message-ID: <14572.54799.686049.313388@beluga.mojam.com> Fred> There is documentation in the distutils CVS repository, at least Fred> skeletal. I'll talk to Greg about just where that should go. Thomas> Try the distutils resource page: Thomas> http://www.python.org/sigs/distutils-sig/ Thanks to both Fred and Thomas. I did eventually work my way around to the SIG page, but only because while grepping the Doc directory I found % tfind . | xargs egrep -i distutils ./ext/ext.tex:\url{http://www.python.org/sigs/distutils-sig/} on the Python Web I thought the CVS repository in .../Lib/distutils was a symlink to the real thing, so any documentation files it contains should have been extracted by "cvs update -d .", right? Skip From akuchlin@mems-exchange.org Thu Apr 6 20:32:08 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 6 Apr 2000 15:32:08 -0400 (EDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <14572.54799.686049.313388@beluga.mojam.com> References: <200004061804.NAA07663@beluga.mojam.com> <14572.57712.838828.602826@seahag.cnri.reston.va.us> <14572.54799.686049.313388@beluga.mojam.com> Message-ID: <14572.58936.493128.494034@amarok.cnri.reston.va.us> Skip Montanaro writes: >I thought the CVS repository in .../Lib/distutils was a symlink to the real >thing, so any documentation files it contains should have been extracted by >"cvs update -d .", right? No; the full Distutils distribution has subdirectories for examples and the actual code. The symlink in the Python CVS tree only points to the subdirectory containing the code, so the examples and the USAGE.txt file don't show up in the Python CVS tree. They'll have to be integrated in at some point. -- A.M. Kuchling http://starship.python.net/crew/amk/ Hey, Michael, you really don't want to go in there. No, really you don't. The Truth hurts, you know... -- Closing lines of ENIGMA #3: "The Good Boy" From thomas.heller@ion-tof.com Thu Apr 6 20:40:13 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 6 Apr 2000 21:40:13 +0200 Subject: [Distutils] How to actually use distutils? References: <200004061804.NAA07663@beluga.mojam.com><14572.57712.838828.602826@seahag.cnri.reston.va.us> <14572.54799.686049.313388@beluga.mojam.com> Message-ID: <031701bf9fff$edcfaaf0$4500a8c0@thomasnotebook> > I thought the CVS repository in .../Lib/distutils was a symlink to the real > thing, so any documentation files it contains should have been extracted by > "cvs update -d .", right? See http://www.python.org/pipermail/distutils-sig/2000-March/001246.html for info about the distutils cvs repository: [Greg wrote] ... Distutils is now available through the Python CVS tree *in addition to its own CVS tree*. That is, if you keep on top of developments in the Python CVS tree, then you will be tracking the latest Distutils code in Lib/distutils. Or, you can keep following the Distutils through its own CVS tree. (This is all done through one itty-bitty little symlink in the CNRI CVS repository, and It Just Works. Cool.) Note that only the 'distutils' subdirectory of the distutils distribution is tracked by Python: that is, changes to the documentation, test suites, and example setup scripts are *not* reflected in the Python CVS tree. ... Thomas Heller From gward@mems-exchange.org Thu Apr 6 20:41:48 2000 From: gward@mems-exchange.org (Greg Ward) Date: Thu, 6 Apr 2000 15:41:48 -0400 Subject: [Distutils] Distutils 0.1.5 released Message-ID: <20000406154147.A13063@mems-exchange.org> Hi all -- I forgot two little fixes in Distutils 0.1.4: handling spaces in filenames under Windows, and suppressing tracebacks for crashes that are not the Distutils' fault. These are now fixed, Distutils 0.1.5 is released, and hopefully I can now lay the 0.1.x codebase to rest and concentrate on 0.8/0.9/1.0. (For the record: 0.8 will be basically the current code; 0.9 will include config files; 1.0 will be what's included with Python 1.6 final. At least that's my plan for now.) Greg From fdrake@acm.org Thu Apr 6 20:56:37 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 6 Apr 2000 15:56:37 -0400 (EDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <14572.54799.686049.313388@beluga.mojam.com> References: <200004061804.NAA07663@beluga.mojam.com> <14572.57712.838828.602826@seahag.cnri.reston.va.us> <14572.54799.686049.313388@beluga.mojam.com> Message-ID: <14572.60405.470198.91523@seahag.cnri.reston.va.us> Skip Montanaro writes: > I thought the CVS repository in .../Lib/distutils was a symlink to the real > thing, so any documentation files it contains should have been extracted by > "cvs update -d .", right? It's a symlink to the distutils package, not the whole thing. The examples, documentation, and README type stuff aren't part of the Python CVS tree at this time. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From skip@mojam.com (Skip Montanaro) Thu Apr 6 19:57:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Thu, 6 Apr 2000 13:57:58 -0500 (CDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <031701bf9fff$edcfaaf0$4500a8c0@thomasnotebook> References: <200004061804.NAA07663@beluga.mojam.com> <14572.57712.838828.602826@seahag.cnri.reston.va.us> <14572.54799.686049.313388@beluga.mojam.com> <031701bf9fff$edcfaaf0$4500a8c0@thomasnotebook> Message-ID: <14572.56886.947335.3503@beluga.mojam.com> Thomas> [Greg wrote] ... Thomas> Note that only the 'distutils' subdirectory of the distutils Thomas> distribution is tracked by Python: that is, changes to the Thomas> documentation, test suites, and example setup scripts are Thomas> *not* reflected in the Python CVS tree. Ah, thanks. This is what I forgot and what new users of distutils will not know. I think it strengthens my argument for a README file in .../Lib/distutils. Skip From fdrake@acm.org Thu Apr 6 21:41:30 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 6 Apr 2000 16:41:30 -0400 (EDT) Subject: [Distutils] How to actually use distutils? In-Reply-To: <14572.56886.947335.3503@beluga.mojam.com> References: <200004061804.NAA07663@beluga.mojam.com> <14572.57712.838828.602826@seahag.cnri.reston.va.us> <14572.54799.686049.313388@beluga.mojam.com> <031701bf9fff$edcfaaf0$4500a8c0@thomasnotebook> <14572.56886.947335.3503@beluga.mojam.com> Message-ID: <14572.63098.652884.49781@seahag.cnri.reston.va.us> Skip Montanaro writes: > Ah, thanks. This is what I forgot and what new users of distutils will not > know. I think it strengthens my argument for a README file in > .../Lib/distutils. I just talked to Greg, and expect we'll have the documentation joined with the other documents within a week or so. I think that's sufficient for Python 1.6, given that he has time to work on manuals. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From calvin@cs.uni-sb.de Fri Apr 7 02:08:04 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Fri, 7 Apr 2000 03:08:04 +0200 (CEST) Subject: [Distutils] What about an info command? Message-ID: Hello, I'd like to extract some information stored in setup.py, namely the package version. A way to provide this is an "info" command. So you can have: ./setup.py info [--version,--name,--url,--author,...] Heres a patch. It prints the infos in a specific order (as specified in user_options), each on its own line. It even prints if you specify -q. You should specify -q because then you get rid of the "running info" line. So as a result "python setup.py -q info --version" prints exactly the package version, nothing more, nothing less. Bastian Kleineidam diff -c -r --ignore-all-space --exclude=*.pyc -N distutils.orig/distutils/command/__init__.py distutils.patched/distutils/command/__init__.py *** distutils.orig/distutils/command/__init__.py Fri Mar 31 12:16:06 2000 --- distutils.patched/distutils/command/__init__.py Fri Apr 7 02:40:42 2000 *************** *** 12,17 **** --- 12,18 ---- 'install', 'install_lib', 'clean', + 'info', 'sdist', 'bdist', 'bdist_dumb', diff -c -r --ignore-all-space --exclude=*.pyc -N distutils.orig/distutils/command/info.py distutils.patched/distutils/command/info.py *** distutils.orig/distutils/command/info.py Thu Jan 1 01:00:00 1970 --- distutils.patched/distutils/command/info.py Fri Apr 7 03:02:39 2000 *************** *** 0 **** --- 1,30 ---- + """distutils.command.info + + Implements the Distutils 'info' command.""" + + from distutils.core import Command + + class info (Command): + + description = "print infos stored in setup.py" + user_options = [ + ('version', 'V', "print version"), + ('author', None, "print author"), + ('author-email', None, "print the authors email"), + ('description', None, "print description"), + ('url', None, "print url"), + # more if needed... + ] + + def initialize_options(self): + for arg in map(lambda x: x[0], self.user_options): + # do not set to None: see Command.__getattr__ + setattr(self, arg, 0) + + def finalize_options(self): + pass + + def run(self): + for arg in map(lambda x: x[0], self.user_options): + if getattr(self, arg): + print getattr(self.distribution, arg) From calvin@cs.uni-sb.de Fri Apr 7 12:47:59 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Fri, 7 Apr 2000 13:47:59 +0200 (CEST) Subject: [Distutils] Installation on Win2K In-Reply-To: Message-ID: >Program Files. If I want to set up a path programatically to my VC++ >files (inside Visual studio) how do I know to use MICROS~1 rather than >MICROS~6? I dont know how to tell which short entry correlates to which long directory entry. But you can use always the long entry when you quote it. So use this: set PATH=c:\windows;"c:\program files\microsoft visual studio\vc98\bin" Bastian From gward@python.net Sun Apr 9 03:02:24 2000 From: gward@python.net (Greg Ward) Date: Sat, 8 Apr 2000 22:02:24 -0400 Subject: [Distutils] Distutils prerequisites Message-ID: <20000408220224.A829@beelzebub> Hi all -- I've just added a "requirements" section to the Distutils README to explain the need for Python 1.5.2 (for now), and the problem with certain Linux distributions that break Python into several packages. Here's what I have so far: REQUIREMENTS ------------ Distutils 0.8 require Python 1.5.2 or later. Under Unix, you must have a *complete* Python installation, including the Makefile and config.h used to build Python. These should be in /lib/python1.X/config (where is the value of the --exec-prefix option to Python's configure script, by default "/usr/local"). Certain Linux distributions break Python up into multiple packages; you should make sure you have all required packages installed: Red Hat python, python-devel SuSE ??? Mandrake ??? Debian ??? Can anyone help me fill in the blanks here? Are there other distributions I should be listing? Do any of the *BSD's include Python, and if so, do they break it up in this way? Also, what are the requirements on Windows? AFAIK all you need to install the Distutils proper is Python 1.5.2 or later (keep in mind that I have only made 1.5.1 compat. changes to the 0.1.x code -- I still need to port those changes to the current code). But to build extensions, I *think* it goes like this: * Visual C++ 5.x or 6.x (what can x equal?) * Python 1.5.x only: win32api and win32con modules recommended (for registry access, which is provided by the standard winreg module in Python 1.6) Anything else? Greg -- Greg Ward - Unix nerd gward@python.net 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. From gward@python.net Mon Apr 10 00:57:26 2000 From: gward@python.net (Greg Ward) Date: Sun, 9 Apr 2000 19:57:26 -0400 Subject: [Distutils] What about an info command? In-Reply-To: ; from Bastian Kleineidam on Fri, Apr 07, 2000 at 03:08:04AM +0200 References: Message-ID: <20000409195726.A566@beelzebub> On 07 April 2000, Bastian Kleineidam said: > I'd like to extract some information stored in setup.py, namely > the package version. Yeah, good idea. > A way to provide this is an "info" command. So you can have: > ./setup.py info [--version,--name,--url,--author,...] I'm not sure this is the right way to do it. Although in general I like the modularity of the "command" system, I think this information is so fundamental to the distribution that it belongs in the Distribution class -- note the query methods 'get_name()', 'has_ext_modules()', etc. that I recently added; this would be in the same vein. This implies hacking the 'parse_command_line()' in dist.py -- feel free to refactor this sucker if you spot a good way to break it up. (...he inspects the code...) Let me rephrase that: *please* find a way to break this method up and refactor it. And then work in the following options: --name -> "Distutils" --version -> "0.8" --fullname -> "Distutils-0.8" --author -> "Greg Ward" --author-email -> "gward@python.net" --maintainer -> "" --maintainer-email -> "" --contact -> maintainer if present, else author --contact-email -> maintainer_email if present, else author_email --url -> "http://www.python.org/sigs/distutils-sig/" --description -> "Python Distribution Utilities" The logic for --name, --version, and --fullname is already in the 'get_name()', 'get_version()', and 'get_full_name()' methods of Distribution; you should add 'get_contact()' and 'get_contact_email()' methods to support the two --contact options. Other than that, direct attribute access should work. These methods should all act like --help -- not an error, but once seen, we won't run any commands, no matter what else is on the command line. Thanks for the idea -- looking forward to a new patch! Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ We have always been at war with Oceania. From jlj@cfd1.cfdrc.com Mon Apr 10 15:10:20 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Mon, 10 Apr 2000 09:10:20 -0500 Subject: [Distutils] RE: Distutils prerequisites (Greg Ward) In-Reply-To: <20000409160013.E60831CD2B@dinsdale.python.org> Message-ID: <002e01bfa2f6$81521d00$4e574dc0@coltrane.cfdrc.com> > > Also, what are the requirements on Windows? AFAIK all you need to > install the Distutils proper is Python 1.5.2 or later (keep in mind that > I have only made 1.5.1 compat. changes to the 0.1.x code -- I still need > to port those changes to the current code). But to build extensions, I > *think* it goes like this: > > * Visual C++ 5.x or 6.x (what can x equal?) > * Python 1.5.x only: win32api and win32con modules recommended > (for registry access, which is provided by the standard > winreg module in Python 1.6) > Visual C++ versions 5 and 6 only had ".0" releases (no intermediate releases like VC++ 4.2), so for your first requirement x = '0'. There are a few service packs available for VC++ 6 but I don't believe any of them were *required* for building Python extensions. A little off-topic, maybe, but hopefully the Distutils will also be able to support building Python extensions on Windows using the Mingw32 compiler system (i.e. the Win32 "ports" of gcc and friends). I know that I've seen a HOWTO about building Python extensions on Win32 using Mingw32 somewhere... From oli@rz-online.net Mon Apr 10 15:40:46 2000 From: oli@rz-online.net (Oliver Andrich) Date: Mon, 10 Apr 2000 16:40:46 +0200 Subject: [Distutils] Distutils prerequisites In-Reply-To: <20000408220224.A829@beelzebub>; from gward@python.net on Sat, Apr 08, 2000 at 10:02:24PM -0400 References: <20000408220224.A829@beelzebub> Message-ID: <20000410164046.B26376@owl.rhein-zeitung.de> On Sat, Apr 08, 2000 at 10:02:24PM -0400, Greg Ward wrote: > Red Hat python, python-devel > SuSE ??? Mandrake python, python-devel > Debian ??? Hi, for Mandrake we have the same requirements as RedHat. Mandrake follows Mandrake in this issue very closely. Best regards, Oliver From calvin@cs.uni-sb.de Mon Apr 10 16:44:25 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Mon, 10 Apr 2000 17:44:25 +0200 (CEST) Subject: [Distutils] Distutils prerequisites In-Reply-To: <20000410164046.B26376@owl.rhein-zeitung.de> Message-ID: > Debian python-base, python-dev From hoel@germanlloyd.org Tue Apr 11 17:16:16 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Tue, 11 Apr 2000 18:16:16 +0200 Subject: [Distutils] Dead link on Python Distutils-SIG: Implementation Status page Message-ID: <38F34FD0.199CBA0C@GermanLloyd.org> Hello, The Python Distutils-SIG: Implementation Status page (http://www.python.org/sigs/distutils-sig/status.html) has a dead link saying it goes to "see the Distutils documentation page" (http://www.python.org/sigs/doc/). That page does not exist. Cheers Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From gward@python.net Wed Apr 12 03:34:12 2000 From: gward@python.net (Greg Ward) Date: Tue, 11 Apr 2000 22:34:12 -0400 Subject: [Distutils] ANNOUNCE: Distutils 0.8 released Message-ID: <20000411223412.A643@beelzebub> Python Distribution Utilities release 0.8 April 11, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6; if you are running 1.6, you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward@python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig@python.org. Here are the changes in release 0.8, if you're curious: * some incompatible naming changes in the command classes -- both the classes themselves and some key class attributes were renamed (this will break some old setup scripts -- see README.txt) * half-hearted, unfinished moves towards backwards compatibility with Python 1.5.1 (the 0.1.4 and 0.1.5 releases were done independently, and I still have to fold those code changes in to the current code) * added ability to search the Windows registry to find MSVC++ (thanks to Robin Becker and Thomas Heller) * renamed the "dist" command to "sdist" and introduced the "manifest template" file (MANIFEST.in), used to generate the actual manifest * added "build_clib" command to build static C libraries needed by Python extensions * fixed the "install" command -- we now have a sane, usable, flexible, intelligent scheme for doing standard, alternate, and custom installations (and it's even documented!) (thanks to Fred Drake and Guido van Rossum for design help) * straightened out the incompatibilities between the UnixCCompiler and MSVCCompiler classes, and cleaned up the whole mechanism for compiling C code in the process * reorganized the build directories: now build to either "build/lib" or "build/lib.", with temporary files (eg. compiler turds) in "build/temp." * merged the "install_py" and "install_ext" commands into "install_lib" -- no longer any sense in keeping them apart, since pure Python modules and extension modules build to the same place * added --debug (-g) flag to "build_*" commands, and make that carry through to compiler switches, names of extensions on Windows, etc. * fixed many portability bugs on Windows (thanks to many people) * beginnings of support for Mac OS (I'm told that it's enough for the Distutils to install itself) (thanks to Corran Webster) * actually pay attention to the "--rpath" option to "build_ext" (thanks to Joe Van Andel for spotting this lapse) * added "clean" command (thanks to Bastien Kleineidam) * beginnings of support for creating built distributions: changes to the various build and install commands to support it, and added the "bdist" and "bdist_dumb" commands * code reorganization: split core.py up into dist.py and cmd.py, util.py into *_util.py * removed global "--force" option -- it's now up to individual commands to define this if it makes sense for them * better error-handling (fewer extravagant tracebacks for errors that really aren't the Distutils' fault -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ All the world's a stage and most of us are desperately unrehearsed. From gward@python.net Wed Apr 12 03:58:04 2000 From: gward@python.net (Greg Ward) Date: Tue, 11 Apr 2000 22:58:04 -0400 Subject: [Distutils] RE: Distutils prerequisites (Greg Ward) In-Reply-To: <002e01bfa2f6$81521d00$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Mon, Apr 10, 2000 at 09:10:20AM -0500 References: <20000409160013.E60831CD2B@dinsdale.python.org> <002e01bfa2f6$81521d00$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000411225804.F828@beelzebub> On 10 April 2000, Lyle Johnson said: > A little off-topic, maybe, but hopefully the Distutils will also be able to > support building Python extensions on Windows using the Mingw32 compiler > system (i.e. the Win32 "ports" of gcc and friends). I know that I've seen a > HOWTO about building Python extensions on Win32 using Mingw32 somewhere... That would definitely be desirable, but it'll have to be contributed by someone in the Python/Windows community -- I spend as little time in Windows as I can get away with. Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ One man's theology is another man's belly laugh. From gward@python.net Wed Apr 12 04:06:09 2000 From: gward@python.net (Greg Ward) Date: Tue, 11 Apr 2000 23:06:09 -0400 Subject: [Distutils] RE: Distutils prerequisites (Greg Ward) In-Reply-To: <002e01bfa2f6$81521d00$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Mon, Apr 10, 2000 at 09:10:20AM -0500 References: <20000409160013.E60831CD2B@dinsdale.python.org> <002e01bfa2f6$81521d00$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000411230609.G828@beelzebub> On 10 April 2000, Lyle Johnson said: > Visual C++ versions 5 and 6 only had ".0" releases (no intermediate releases > like VC++ 4.2), so for your first requirement x = '0'. There are a few > service packs available for VC++ 6 but I don't believe any of them were > *required* for building Python extensions. OK, here's the updated "REQUIREMENTS" section in the Distutils README.txt: Release 0.8 of the Distutils requires Python 1.5.2 or later. (Compatibility with Python 1.5.1 is forthcoming, as soon as I merge the 1.5.1 compatibility changes from Distutils 0.1.4 and 0.1.5 forward.) To use the Distutils under Unix, you must have a *complete* Python installation, including the Makefile and config.h used to build Python. These should be in /lib/python1.X/config. ( is the value of the --exec-prefix option to Python's configure script, or the --prefix option if --exec-prefix wasn't supplied; if neither was supplied, the default is "/usr/local". If you don't know your , fire up the Python interpreter and type "import sys ; sys.exec_prefix".) Certain Linux distributions break Python up into multiple packages; you should make sure you have all required packages installed: Red Hat python, python-devel Mandrake python, python-devel SuSE python Debian python-base, python-dev In order to build extensions on any platform, you will need a C/C++ compiler. On Unix, the compiler used to build Python itself will be used by default, and should do the trick; if you didn't build Python, then hopefully you'll find out pretty quickly whether building extensions works or not. To build extensions on Windows, you need Microsoft Visual C++ 5.0 or 6.0. It also helps to have access to the Windows registry from Python; if you have the Win32 extensions (win32api, win32con) installed, you're fine. (Python 1.6 includes the winreg module for this purpose, which the Distutils will use if available.) If not, the Distutils might not be able to find the Visual C++ executables. The last two paragraphs didn't make it into Distutils 0.8: oh well. Just as well, I want to make sure that last paragraph is accurate first! Please tell me how close I am to reality there... Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ I appoint you ambassador to Fantasy Island!!! From jlj@cfd1.cfdrc.com Wed Apr 12 22:09:28 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Wed, 12 Apr 2000 16:09:28 -0500 Subject: [Distutils] Possible fix for sysconfig.py (Win32) Message-ID: <004001bfa4c3$63404e80$4e574dc0@coltrane.cfdrc.com> The call to parse_config_h() in _init_nt() [both found in distutils/sysconfig.py] clobbers the previously correct values of PREFIX and EXEC_PREFIX for the standard Python installation on Win32. This in turn leads to the compiler picking up the wrong Python include file paths (and probably other glitches I haven't stumbled onto yet). One workaround (the one I've used) is to comment out that call to parse_config_h() ;) From jlj@cfd1.cfdrc.com Wed Apr 12 23:43:19 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Wed, 12 Apr 2000 17:43:19 -0500 Subject: [Distutils] Patch for build_ext.py (Win32) Message-ID: <004801bfa4d0$7fa732c0$4e574dc0@coltrane.cfdrc.com> Here's a patch for distutils/command/build_ext.py to ensure that the output directory for scratch files created while building the extension DLL actually exists. Index: build_ext.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/build_ext.py,v retrieving revision 1.30 diff -c -r1.30 build_ext.py *** build_ext.py 2000/04/10 00:19:42 1.30 --- build_ext.py 2000/04/12 22:33:10 *************** *** 331,336 **** --- 331,342 ---- implib_dir = os.path.join(self.build_temp,\ self.get_ext_libname(extension_name)) extra_args.append ('/IMPLIB:' + implib_dir) + + # Ensure that this directory exists! + ext_path = string.split(extension_name, '.') + ext_path = apply(os.path.join, ext_path[:-1]) + self.mkpath(os.path.join(self.build_temp, ext_path)) + # if MSVC fullname = self.get_ext_fullname (extension_name) From jlj@cfd1.cfdrc.com Wed Apr 12 23:46:05 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Wed, 12 Apr 2000 17:46:05 -0500 Subject: [Distutils] Patch for msvccompiler.py (Win32) Message-ID: <004901bfa4d0$e2c7f010$4e574dc0@coltrane.cfdrc.com> Here's a patch for distutils/msvccompiler.py to ensure that the appropriate Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in with your extension DLL on Windows. As my comment indicates, there's probably a cleaner way to pick up the correct library name but this should work for Python 1.5.x and Python 1.6. Index: msvccompiler.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/msvccompiler.py,v retrieving revision 1.25 diff -c -r1.25 msvccompiler.py *** msvccompiler.py 2000/03/31 19:04:25 1.25 --- msvccompiler.py 2000/04/12 22:43:28 *************** *** 329,334 **** --- 329,346 ---- extra_preargs=None, extra_postargs=None): + # Add the Python library to the standard library list. + # There's probably a more elegant way to determine the correct name ;) + if sys.winver == '1.5': + pythonlib = 'python15' + else: + pythonlib = 'python16' + + if debug: + pythonlib = pythonlib + '_d' + + self.add_library(pythonlib) + (objects, output_dir) = self._fix_object_args (objects, output_dir) (libraries, library_dirs, runtime_library_dirs) = \ self._fix_lib_args (libraries, library_dirs, runtime_library_dirs) From thomas.heller@ion-tof.com Thu Apr 13 09:04:53 2000 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Thu, 13 Apr 2000 10:04:53 +0200 Subject: [Distutils] Patch for msvccompiler.py (Win32) References: <004901bfa4d0$e2c7f010$4e574dc0@coltrane.cfdrc.com> Message-ID: <003a01bfa51e$f37bc500$4500a8c0@thomasnotebook> > Here's a patch for distutils/msvccompiler.py to ensure that the appropriate > Python import library (e.g. "python15.lib" or "python15_d.lib") is linked in > with your extension DLL on Windows. I never had any problems with this: the Python header files ensure this by a pragma. You (or distutils) don't have to care about this. Thomas Heller From hoel@germanlloyd.org Thu Apr 13 14:23:13 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Apr 2000 15:23:13 +0200 Subject: [Distutils] link_executable for msvccompiler Message-ID: <38F5CA41.424CB0F2@GermanLloyd.org> Hello, I had urgent need for link_executable for msvccompiler. So I took link_shared_object, copied to link_executable and made it work for executables. See the attached result of my hacking: Cheers Berthold (insert the following to msvccompiler.py) def link_executable (self, objects, output_execname, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, debug=0, extra_preargs=None, extra_postargs=None): output_filename = output_execname + self.exe_extension (objects, output_dir) = self._fix_object_args (objects, output_dir) (libraries, library_dirs, runtime_library_dirs) = \ self._fix_lib_args (libraries, library_dirs, runtime_library_dirs) if self.runtime_library_dirs: self.warn ("I don't know what to do with 'runtime_library_dirs': " + str (runtime_library_dirs)) lib_opts = gen_lib_options (self, library_dirs, runtime_library_dirs, libraries) if type (output_dir) not in (StringType, NoneType): raise TypeError, "'output_dir' must be a string or None" if output_dir is not None: output_filename = os.path.join (output_dir, output_filename) if self._need_link (objects, output_filename): if debug: ldflags = self.ldflags_shared_debug[1:] else: ldflags = self.ldflags_shared[1:] ld_args = ldflags + lib_opts + \ objects + ['/OUT:' + output_filename] if extra_preargs: ld_args[:0] = extra_preargs if extra_postargs: ld_args.extend (extra_postargs) self.mkpath (os.path.dirname (output_filename)) self.spawn ([self.link] + ld_args) else: self.announce ("skipping %s (up-to-date)" % output_filename) -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From hoel@germanlloyd.org Thu Apr 13 14:42:19 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Apr 2000 15:42:19 +0200 Subject: [Distutils] link_executable for msvccompiler References: <38F5CA41.424CB0F2@GermanLloyd.org> Message-ID: <38F5CEBB.6632F112@GermanLloyd.org> Berthold Hoellmann wrote: > > Hello, > > I had urgent need for link_executable for msvccompiler. So I took > link_shared_object, copied to link_executable and made it work for > executables. See the attached result of my hacking: Excuse me, that I reply to my own post, but I forgot to mention, that I made this change in a copy of distutils 0.8. Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From jlj@cfd1.cfdrc.com Thu Apr 13 14:41:17 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Thu, 13 Apr 2000 08:41:17 -0500 Subject: [Distutils] Patch for msvccompiler.py (Win32) In-Reply-To: <003a01bfa51e$f37bc500$4500a8c0@thomasnotebook> Message-ID: <001501bfa54d$f1ec18f0$4e574dc0@coltrane.cfdrc.com> Now that you mention it, that does sound familiar ;) Nevertheless, when I started trying to use the Distutils-0.8 distro to build my Python extension under Windows it came up with numerous unresolved symbols (Python library calls) until I used this modification to actually list python15.lib (or python15_d.lib) on the link line. I'll investigate this some more today to see if I can figure out what's going wrong here. > -----Original Message----- > From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > Sent: Thursday, April 13, 2000 3:05 AM > To: Lyle Johnson; distutils-sig@python.org > Subject: Re: [Distutils] Patch for msvccompiler.py (Win32) > > > > Here's a patch for distutils/msvccompiler.py to ensure that the > appropriate > > Python import library (e.g. "python15.lib" or "python15_d.lib") > is linked in > > with your extension DLL on Windows. > I never had any problems with this: the Python header files > ensure this by a pragma. > You (or distutils) don't have to care about this. > > Thomas Heller > From jlj@cfd1.cfdrc.com Thu Apr 13 14:43:28 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Thu, 13 Apr 2000 08:43:28 -0500 Subject: [Distutils] Voodoo Python Message-ID: <001601bfa54e$3f75f370$4e574dc0@coltrane.cfdrc.com> Please disregard the patch for msvccompiler.py which I submitted yesterday. After Thomas' e-mail I went back to try to reproduce the problem with the (unpatched) version of msvccompiler.py and it worked like a charm. Maybe I just needed a good night's sleep. From hoel@germanlloyd.org Thu Apr 13 15:19:33 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Apr 2000 16:19:33 +0200 Subject: [Distutils] problem when installing under WinNT Message-ID: <38F5D775.8BA159D6@GermanLloyd.org> Hello, 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)? Thanks Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From hoel@germanlloyd.org Thu Apr 13 15:30:05 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Apr 2000 16:30:05 +0200 Subject: [Distutils] Bug in distutils 0.8 Message-ID: <38F5D9ED.9EC2A077@GermanLloyd.org> Hello, 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 Greetings Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From hoel@germanlloyd.org Thu Apr 13 16:47:18 2000 From: hoel@germanlloyd.org (Berthold Hoellmann) Date: Thu, 13 Apr 2000 17:47:18 +0200 Subject: [Distutils] problem with installing NumPy under WinNT Message-ID: <38F5EC06.FF0E2D8@GermanLloyd.org> Hello, 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 '""' >>> I guess, sysconfig.EXEC_PREFIX should return '"G:\\bin\\Python"', but I have no idea, what's going wrong here. Thanks Berthold -- email: hoel@GermanLloyd.org ) ( C[_] These opinions might be mine, but never those of my employer. From gward@python.net Fri Apr 14 01:37:53 2000 From: gward@python.net (Greg Ward) Date: Thu, 13 Apr 2000 20:37:53 -0400 Subject: [Distutils] Possible fix for sysconfig.py (Win32) In-Reply-To: <004001bfa4c3$63404e80$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Wed, Apr 12, 2000 at 04:09:28PM -0500 References: <004001bfa4c3$63404e80$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000413203753.C480@beelzebub> On 12 April 2000, Lyle Johnson said: > The call to parse_config_h() in _init_nt() [both found in > distutils/sysconfig.py] clobbers the previously correct values of PREFIX and > EXEC_PREFIX for the standard Python installation on Win32. This in turn > leads to the compiler picking up the wrong Python include file paths (and > probably other glitches I haven't stumbled onto yet). Oops! Hmm, I can't see that happening with the config.h on my Linux box: does the config.h installed for Windows "#define PREFIX" and "#define EXEC_PREFIX"? If so, that's what's going on. Anyways, commenting out that line is just fine. In fact, it seems to me that there is no reason to read config.h on any platform, and very little reason even to keep that code around. The information read from config.h simply isn't used anywhere in the Distutils. Fred, what's your take on this? Should we just ditch the config.h-reading code from sysconfig.py? Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ Whatever became of eternal truth? From gward@python.net Fri Apr 14 01:45:59 2000 From: gward@python.net (Greg Ward) Date: Thu, 13 Apr 2000 20:45:59 -0400 Subject: [Distutils] Patch for build_ext.py (Win32) In-Reply-To: <004801bfa4d0$7fa732c0$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Wed, Apr 12, 2000 at 05:43:19PM -0500 References: <004801bfa4d0$7fa732c0$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000413204559.D480@beelzebub> On 12 April 2000, Lyle Johnson said: > Here's a patch for distutils/command/build_ext.py to ensure that the output > directory for scratch files created while building the extension DLL > actually exists. No, it's the job of the CCompiler classes to ensure that the files they are about to write can be written, ie. that os.path.dirname(output_file) exists before running the compile/link/whatever that attempts to create output_file. In fact, if you look in msvccompiler.py, in the 'link_shared_object()' method, you see it being done: if self._need_link (objects, output_filename): if debug: ldflags = self.ldflags_shared_debug else: ldflags = self.ldflags_shared ld_args = ldflags + lib_opts + \ objects + ['/OUT:' + output_filename] if extra_preargs: ld_args[:0] = extra_preargs if extra_postargs: ld_args.extend (extra_postargs) >>>> self.mkpath (os.path.dirname (output_filename)) <<<<<< self.spawn ([self.link] + ld_args) else: self.announce ("skipping %s (up-to-date)" % output_filename) So something must be going wrong with that 'mkpath()' call. Try applying *this* patch and see if it sheds any light on the matter: *** msvccompiler.py 2000/03/31 19:04:25 1.25 --- msvccompiler.py 2000/04/14 00:45:43 *************** *** 360,365 **** --- 360,368 ---- if extra_postargs: ld_args.extend (extra_postargs) + print "link_shared_object():" + print " output_filename =", output_filename + print " mkpath'ing:", os.path.dirname (output_filename) self.mkpath (os.path.dirname (output_filename)) self.spawn ([self.link] + ld_args) Let me know if you figure out what's going on. Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I want to so HAPPY, the VEINS in my neck STAND OUT!! From gward@python.net Fri Apr 14 01:34:41 2000 From: gward@python.net (Greg Ward) Date: Thu, 13 Apr 2000 20:34:41 -0400 Subject: [Distutils] Patch for msvccompiler.py (Win32) In-Reply-To: <003a01bfa51e$f37bc500$4500a8c0@thomasnotebook>; from Thomas Heller on Thu, Apr 13, 2000 at 10:04:53AM +0200 References: <004901bfa4d0$e2c7f010$4e574dc0@coltrane.cfdrc.com> <003a01bfa51e$f37bc500$4500a8c0@thomasnotebook> Message-ID: <20000413203441.B480@beelzebub> [Lyle Johnson] > Here's a patch for distutils/msvccompiler.py to ensure that the > appropriate Python import library (e.g. "python15.lib" or > "python15_d.lib") is linked in with your extension DLL on Windows. msvccompiler.py is not the right sort of place for patches like this; I'm trying to keep the *CCompiler classes from being specific to building Python extensions. Or rather, from getting any more specific to building Python extensions than they already are (he says, having just poked through unixccompiler.py to see what it imports from sysconfig). But the point is moot: [Thomas Heller] > I never had any problems with this: the Python header files ensure > this by a pragma. You (or distutils) don't have to care about this. It has just occurred to me that those pragmas are awfully handy things, but can we rely on them? What if someone wants to build Python extensions with the Windows port of gcc, or with Borland's newly free-as-in-free-beer compiler? (I imagine they'll have a big job, as they'll probably have to start with building Python itself with said compiler. But this might be yet another little problem along that road.) IOW, perhaps build_ext.py should have yet another bit of Windows-specific code -- not MSVC-specific this time, but Windows-specific -- to (maybe) add the Python DLL to the link. Thoughts? Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Disclaimer: All rights reserved. Void where prohibited. Limit 1 per customer. From mhammond@skippinet.com.au Fri Apr 14 04:21:57 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 14 Apr 2000 13:21:57 +1000 Subject: [Distutils] Patch for msvccompiler.py (Win32) In-Reply-To: <20000413203441.B480@beelzebub> Message-ID: > It has just occurred to me that those pragmas are awfully > handy things, > but can we rely on them? 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. Also, any .libs specified on the command line will be searched before onces specified by the pragmas - meaning the command line effectively overrides it. > What if someone wants to build Python > extensions with the Windows port of gcc, or with Borland's newly > free-as-in-free-beer compiler? (I imagine they'll have a > big job, as > they'll probably have to start with building Python > itself with said > compiler. But this might be yet another little problem along that > road.) If they dont support the pragma (which I bet they will), then it is simply #ifdef'd around an MS specific variable. I think this would be the least of their problems! Mark. From fdrake@acm.org Fri Apr 14 14:15:37 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 14 Apr 2000 09:15:37 -0400 (EDT) Subject: [Distutils] Possible fix for sysconfig.py (Win32) In-Reply-To: <20000413203753.C480@beelzebub> References: <004001bfa4c3$63404e80$4e574dc0@coltrane.cfdrc.com> <20000413203753.C480@beelzebub> Message-ID: <14583.6649.957392.122799@seahag.cnri.reston.va.us> Greg Ward writes: > Anyways, commenting out that line is just fine. In fact, it seems to me > that there is no reason to read config.h on any platform, and very > little reason even to keep that code around. The information read from > config.h simply isn't used anywhere in the Distutils. Fred, what's your > take on this? Should we just ditch the config.h-reading code from > sysconfig.py? If none of the information is being used, then let's comment out the call to read the file. When building the modules in Modules/, I notice that -DHAVE_CONFIG_H is passed on the command line, but that indicates distutils should make that define from the command line if appropriate (or perhaps always?). The file itself may not need to be parsed by distutils. I'd keep the function around, since a specific package may benefit from having that information around; the setup.py for that can call the function if appropriate. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From jlj@cfd1.cfdrc.com Fri Apr 14 18:00:36 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Fri, 14 Apr 2000 12:00:36 -0500 Subject: [Distutils] Patch for build_ext.py (Win32) In-Reply-To: <20000414160017.8A70F1CD84@dinsdale.python.org> Message-ID: <000801bfa632$f4799e90$4e574dc0@coltrane.cfdrc.com> > No, it's the job of the CCompiler classes to ensure that the files they > are about to write can be written, ie. that os.path.dirname(output_file) > exists before running the compile/link/whatever that attempts to create > output_file. > Yes, the problem is that during the link (i.e. when we're actually making the Windows DLL) it actually creates (well, tries to create) the following *three* files: build\lib.win32\MyExtensionName.pyd build\temp.win32\Release\MyExtensionName.lib build\temp.win32\Release\MyExtensionName.exp For the record, here's what my distutils-conjured link line looks like: link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:../dtf \ /LIBPATH:D:\Progra~1\Python\libs DTF.lib \ build\temp.win32\Release\core_wrap.obj \ /OUT:build\lib.win32\dtf\core.pyd /export:initcore \ /IMPLIB:build\temp.win32\Release\dtf\core.lib You are correct that link_shared_object() takes care of mkpath'ing the output directory for the DLL itself but it does *not* create the needed directories for the scratch files ("core.lib" and "core.exp"). So perhaps the patch that I originally suggested for build_ext.py should be moved into link_shared_object() instead. It doesn't matter to me as long as somebody creates that directory before we try to dump files into it ;) Lyle From gward@ase.com Tue Apr 18 03:46:36 2000 From: gward@ase.com (Greg Ward) Date: Mon, 17 Apr 2000 22:46:36 -0400 Subject: [Distutils] Alternate email address Message-ID: <20000417224636.A970@beelzebub> Anyone who has been trying to send me mail since last Friday: please resend it to gward@ase.com; as long as python.net is down, this will be my substitute address. Greg -- Greg Ward - Linux weenie gward@ase.com http://starship.python.net/~gward/ If you're not part of the solution, you're part of the precipitate. From mike@pdc.kth.se Tue Apr 18 17:52:44 2000 From: mike@pdc.kth.se (Mike Hammill) Date: Tue, 18 Apr 2000 18:52:44 +0200 Subject: [Distutils] distutils+numpy problem on AIX Message-ID: <200004181652.SAA32333@ratatosk.pdc.kth.se> Hello, 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 Background: 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 According to one is supposed to replace the Numerical part of the 11 distribution with the 14 one. I did this and then went to the Numerical subdirectory to install it. Following the suggestion in the README.txt in the distribution of Distutils-0.8, I replaced the setup.py file in Numerical with the one that comes in the examples directory of Distutils-0.8. When I ran python (1.5.2) with this, I get the messages below. Does anyone have any idea what might be going wrong? Notes: Python 1.5.2 seems to test fine on our SP (AIX 4.3). I installed it in a non-standard place (my directory) for testing. python setup.py install running install running build running build_py not copying Lib/ArrayPrinter.py (output up-to-date) not copying Lib/FFT.py (output up-to-date) not copying Lib/LinearAlgebra.py (output up-to-date) not copying Lib/MLab.py (output up-to-date) not copying Lib/Matrix.py (output up-to-date) not copying Lib/Numeric.py (output up-to-date) not copying Lib/Precision.py (output up-to-date) not copying Lib/RandomArray.py (output up-to-date) not copying Lib/UserArray.py (output up-to-date) running build_ext building '_numpy' extension skipping Src/_numpymodule.c (build/temp.aix3-002005909400/Src/_numpymodule.o up-to-date) skipping Src/arrayobject.c (build/temp.aix3-002005909400/Src/arrayobject.o up-to-date) skipping Src/ufuncobject.c (build/temp.aix3-002005909400/Src/ufuncobject.o up-to-date) ./ld_so_aix cc build/temp.aix3-002005909400/Src/_numpymodule.o build/temp.aix3-002005909400/Src/arrayobject.o build/temp.aix3-002005909400/Src /ufuncobject.o -o build/lib.aix3-002005909400/_numpy.so unable to execute ./ld_so_aix: No such file or directory error: command './ld_so_aix' failed with exit status 1 By the way, after this failure, I tried to just install NumPy strickly from LLNL's "11" distribution, using makethis.py. I get a different, but similar message, python makethis.py Listing . ... Listing ./Demo ... Compiling ./Demo/life.py ... Compiling ./Demo/mandelbrot.py ... Compiling ./Demo/sieve.py ... Listing ./Doc ... Listing ./Include ... Listing ./Lib ... Compiling ./Lib/ArrayPrinter.py ... Compiling ./Lib/FFT.py ... Compiling ./Lib/LinearAlgebra.py ... Compiling ./Lib/MLab.py ... Compiling ./Lib/Matrix.py ... Compiling ./Lib/Numeric.py ... Compiling ./Lib/Precision.py ... Compiling ./Lib/RandomArray.py ... Compiling ./Lib/UserArray.py ... Listing ./Src ... Listing ./Test ... Compiling ./Test/test_all.py ... Compiling ./installthis.py ... Compiling ./makethis.py ... rm -f *.o *~ rm -f *.a tags TAGS config.c Makefile.pre python sedscript rm -f *.so *.sl so_locations VERSION=`python -c "import sys; print sys.version[:3]"`; \ installdir=`python -c "import sys; print sys.prefix"`; \ exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \ make -f ./Makefile.pre.in VPATH=. srcdir=. \ VERSION=$VERSION \ installdir=$installdir \ exec_installdir=$exec_installdir \ Makefile make[1]: Entering directory `/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/p ymore/numpy/LLNLDistribution11/Numer sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# Generated automatically from Makefile.pre.in by sedscript.%p' \ -e '/^VERSION=/s/^VERSION=[ ]*\(.*\)/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*\(.*\)/s%@CC[@]%\1%/p' \ -e '/^CCC=/s/^CCC=[ ]*\(.*\)/s%#@SET_CCC[@]%CCC=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*\(.*\)/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*\(.*\)/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \ -e '/^LDLAST=/s/^LDLAST=[ ]*\(.*\)/s%@LDLAST[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*\(.*\)/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*\(.*\)/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*\(.*\)/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*\(.*\)/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*\(.*\)/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*\(.*\)/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*\(.*\)/s%@CCSHARED[@]%\1%/p' \ -e '/^SGI_ABI=/s/^SGI_ABI=[ ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \ -e '/^LINKFORSHARED=/s/^LINKFORSHARED=[ ]*\(.*\)/s%@LINKFORSHARED[@]%\1 %/p' \ -e '/^prefix=/s/^prefix=\(.*\)/s%^prefix=.*%prefix=\1%/p' \ -e '/^exec_prefix=/s/^exec_prefix=\(.*\)/s%^exec_prefix=.*%exec_prefix=\1%/p' \ /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/lib/python1.5/config/M akefile >sedscript echo "/^#@SET_CCC@/d" >>sedscript echo "/^installdir=/s%=.*%= /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix4 3/python%" >>sedscript echo "/^exec_installdir=/s%=.*%=/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix4 3/python%" >>sedscript echo "/^srcdir=/s%=.*%= .%" >>sedscript echo "/^VPATH=/s%=.*%= .%" >>sedscript echo "/^LINKPATH=/s%=.*%= %" >>sedscript echo "/^BASELIB=/s%=.*%= %" >>sedscript echo "/^BASESETUP=/s%=.*%= %" >>sedscript sed -f sedscript ./Makefile.pre.in >Makefile.pre /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/lib/python1.5/config/ma kesetup \ -m Makefile.pre -c /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/py thon/lib/python1.5/config/config.c.in /afs/pdc.kth.se/home/m/mike/Python/.bin/ rs_aix43/python/lib/python1.5/config/Setup.thread /afs/pdc.kth.se/home/mhon/.bi n/rs_aix43/python/lib/python1.5/config/Setup.local /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/l1.5/config/Setup make -f Makefile do-it-again make[2]: Entering directory `/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/p ymore/numpy/LLNLDistribution11/Numer /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/lib/python1.5/config/ma kesetup \ -m Makefile.pre -c /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/py thon/lib/python1.5/config/config.c.in /afs/pdc.kth.se/home/m/mike/Python/.bin/ rs_aix43/python/lib/python1.5/config/Setup.thread /afs/pdc.kth.se/home/mhon/.bi n/rs_aix43/python/lib/python1.5/config/Setup.local /afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/l1.5/config/Setup make[2]: Leaving directory `/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/py more/numpy/LLNLDistribution11/Numeri make[1]: Leaving directory `/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/py more/numpy/LLNLDistribution11/Numeri cc -I./Include -O -I/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/i nclude/python1.5 -I/afs/pdc.kth.se/he/Python/.bin/rs_aix43/python/include/pytho n1.5 -DHAVE_CONFIG_H -c ./Src/_numpymodule.c cc -I./Include -O -I/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/i nclude/python1.5 -I/afs/pdc.kth.se/he/Python/.bin/rs_aix43/python/include/pytho n1.5 -DHAVE_CONFIG_H -c ./Src/arrayobject.c "./Src/arrayobject.c", line 1539.10: 1506-342 (W) "/*" detected in comment. cc -I./Include -O -I/afs/pdc.kth.se/home/m/mike/Python/.bin/rs_aix43/python/i nclude/python1.5 -I/afs/pdc.kth.se/he/Python/.bin/rs_aix43/python/include/pytho n1.5 -DHAVE_CONFIG_H -c ./Src/ufuncobject.c ./ld_so_aix cc _numpymodule.o arrayobject.o ufuncobject.o -o _numpymodule.so make: ./ld_so_aix: Command not found make: *** [_numpymodule.so] Error 127 Many thanks, Mike Hammill From gward@ase.com Wed Apr 19 02:00:27 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:00:27 -0400 Subject: [Distutils] Re: Patch for msvccompiler.py (Win32) Message-ID: <20000418210027.A461@beelzebub> [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@ase.com http://starship.python.net/~gward/ Life is too short for ordinary music. From gward@ase.com Wed Apr 19 02:15:43 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:15:43 -0400 Subject: [Distutils] examples/sample3 (was: Bug in distutils 0.8) Message-ID: <20000418211543.A506@beelzebub> Berthold Hoellmann : > 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@ase.com http://starship.python.net/~gward/ I am having FUN... I wonder if it's NET FUN or GROSS FUN? From gward@ase.com Wed Apr 19 02:19:58 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:19:58 -0400 Subject: [Distutils] Case mismatch error? (was: problem when installing under WinNT) Message-ID: <20000418211958.A515@beelzebub> Berthold Hoellmann : > 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@ase.com http://starship.python.net/~gward/ Never put off till tomorrow what you can put off till the day after tomorrow. From gward@ase.com Wed Apr 19 02:29:56 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:29:56 -0400 Subject: [Distutils] problem with installing NumPy under WinNT Message-ID: <20000418212956.A555@beelzebub> Berthold Hoellmann : > 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@ase.com http://starship.python.net/~gward/ Paranoia is simply an optimistic outlook on life. From amk@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com Wed Apr 19 02:45:55 2000 From: amk@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com (A.M. Kuchling) Date: Tue, 18 Apr 2000 21:45:55 -0400 Subject: [Distutils] MANIFEST.in format Message-ID: <200004190145.VAA02450@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com> 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 From gward@ase.com Wed Apr 19 02:42:45 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:42:45 -0400 Subject: [Distutils] distutils+numpy problem on AIX Message-ID: <20000418214245.A572@beelzebub> Mike Hammill : > 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@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. From gward@ase.com Wed Apr 19 02:45:49 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 21:45:49 -0400 Subject: [Distutils] MANIFEST.in format In-Reply-To: <200004190145.VAA02450@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com>; from A.M. Kuchling on Tue, Apr 18, 2000 at 09:45:55PM -0400 References: <200004190145.VAA02450@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com> Message-ID: <20000418214549.A598@beelzebub> On 18 April 2000, A.M. Kuchling said: > 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 Laziness, fear of complex syntax leading to complex code. I think the code turned out to be simple enough that slightly more complex code is allowable, though, so... > Would patches for this change be accepted? ...sure! But the new rule (invented right here on the spot) is that you have to submit doc patches too. ;-) Unless of course the documentation already led you to believe that you could do this, in which case my documentation time machine is in working order (more than you can say for most of my code...) Greg -- Greg Ward - Linux geek gward@ase.com http://starship.python.net/~gward/ A closed mouth gathers no foot. From gward@ase.com Wed Apr 19 03:28:49 2000 From: gward@ase.com (Greg Ward) Date: Tue, 18 Apr 2000 22:28:49 -0400 Subject: [Distutils] New code snapshot Message-ID: <20000418222849.A809@beelzebub> 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@ase.com http://starship.python.net/~gward/ I had a lease on an OEDIPUS COMPLEX back in '81 ... From fdrake@acm.org Wed Apr 19 05:03:56 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 19 Apr 2000 00:03:56 -0400 (EDT) Subject: [Distutils] MANIFEST.in format In-Reply-To: <20000418214549.A598@beelzebub> References: <200004190145.VAA02450@207-172-113-89.s89.tnt5.ann.va.dialup.rcn.com> <20000418214549.A598@beelzebub> Message-ID: <14589.12332.23623.516151@seahag.cnri.reston.va.us> Greg Ward writes: > ...sure! But the new rule (invented right here on the spot) is that you > have to submit doc patches too. ;-) Unless of course the documentation This is a standing rule for the Python tree, so ... it's fair to make it for distutils as well these days. ;) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From jlj@cfd1.cfdrc.com Wed Apr 19 17:19:39 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Wed, 19 Apr 2000 11:19:39 -0500 Subject: [Distutils] Re: Patch for msvccompiler.py (Win32) In-Reply-To: <20000419160023.52B5C1CE46@dinsdale.python.org> Message-ID: <003801bfaa1b$100e3a30$4e574dc0@coltrane.cfdrc.com> > 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 ;) From jlj@cfd1.cfdrc.com Wed Apr 19 17:25:24 2000 From: jlj@cfd1.cfdrc.com (Lyle Johnson) Date: Wed, 19 Apr 2000 11:25:24 -0500 Subject: [Distutils] RE: New code snapshot In-Reply-To: <20000419160023.52B5C1CE46@dinsdale.python.org> Message-ID: <003901bfaa1b$dd3c51e0$4e574dc0@coltrane.cfdrc.com> > 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. From gward@ase.com Thu Apr 20 22:42:36 2000 From: gward@ase.com (Greg Ward) Date: Thu, 20 Apr 2000 17:42:36 -0400 Subject: [Distutils] RE: New code snapshot In-Reply-To: <003901bfaa1b$dd3c51e0$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Wed, Apr 19, 2000 at 11:25:24AM -0500 References: <20000419160023.52B5C1CE46@dinsdale.python.org> <003901bfaa1b$dd3c51e0$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000420174236.A502@beelzebub> On 19 April 2000, Lyle Johnson said: > 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. I couldn't reproduce this -- I tried both Distutils 0.8 and the latest snapshot under Windows today, and the sdist command works fine. (Well, OK, it doesn't work too well with the snapshot, since the snapshot doesn't include the full source distribution. But it didn't get hung up on slashes!) Furthermore, sdist.py hasn't changed since I added the slash-to-backslash fix. Can you post *exactly* what command you ran and what output you got? Thanks -- Greg -- Greg Ward - Linux geek gward@ase.com http://starship.python.net/~gward/ It has just been discovered that research causes cancer in rats. From gward@ase.com Fri Apr 21 00:01:52 2000 From: gward@ase.com (Greg Ward) Date: Thu, 20 Apr 2000 19:01:52 -0400 Subject: [Distutils] Revisiting the "pkginfo" patch Message-ID: <20000420190152.A766@beelzebub> 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@ase.com http://starship.python.net/~gward/ All of life is a blur of Republicans and meat! From mmuller@enduden.com Sat Apr 22 00:38:29 2000 From: mmuller@enduden.com (Michael Muller) Date: Fri, 21 Apr 2000 19:38:29 -0400 Subject: [Distutils] Revisiting the "pkginfo" patch References: <20000420190152.A766@beelzebub> Message-ID: <3900E675.92B53934@enduden.com> Hello again, one moment whilst I swap in some pages... Greg Ward wrote: > * 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 disagree. Distribution contains package meta-info, but it also contains a lot of information that is relevant to a source distribution: packages, modules, source files. PackageInfo includes a subset of that information (package name, version, author...) and it also includes the final set of installed files, which appears to me to be the product of the install commands, not of the Distribution. [correct me if I'm missing something here, obviously you know your code better than I do, particularly since I haven't looked at it in several months]. Furthermore, package information deserves to be seperated out for purposes of modularity: if people want to create alternate forms of the module (based, perhaps, on RPM or DBM files), they should be able to plug their replacement right into the system as long as they conform to a very simple, specific interface. Likewise, programmers using alternate build/distribution technologies should be able to define package information without having to use distutils. > * 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.) Yeah, I thought about that when I wrote it: I added it anyway in hopes that the issue of what "The Right Thing" is would be thrashed out on the SIG. Under the circumstances, I agree that it should be removed (for now, at least). > * 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. It's funny: as I looked at the code again now I was having one of those "what the &^$@ was I thinking???" monents; but then it all came flooding back to me like some twisted repressed memory... The problem is not so much the type checking: it's the persistence. In order to read and write the package information, we need to either have code to write and read each field individually, or have some sort of generalized way of writing and reading different kinds of content. The former approach is difficult to extend and maintain, particularly when you start dealing with complex nested structures. The persistence problem is complicated further by the fact that ConfigParser files favor readability over unambiguous expression. For example, a string with no trailing or leading whitespace and no embedded newlines can (and should) be easily be expressed as "header: value of the string". Strings with special needs require special escapes so that these characters are preserved correctly. In order to simplify things and try to keep the package info file syntax as clear as possible, I decided to do the following: 1) Create classes that know how to read and write certain kinds of data. 2) Map the attributes of the PackageInfo object to instances of these classes so that reading and writing is just a matter of iterating over the attributes and calling the associated 'write()' method. 3) Verify that the attribute types are correct in the PackageInfo constructor to keep an error from occuring at the point where the information is written. This approach also allows us to do context sensitive parsing, which does a great deal to clean up the syntax of the package info file. In the absence of dependency and compatibility information, all of this isn't as important: however, at some point I'm sure it will be desirable to add more complicated information to this object. If it wasn't for the fact that I'd like it to be readable, I'd say we should just pickle the object. I liked the original pprint/execfile approach because it seemed to be the best of both worlds. ============================================================================= michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer ============================================================================= From gward@ase.com Sat Apr 22 03:16:33 2000 From: gward@ase.com (Greg Ward) Date: Fri, 21 Apr 2000 22:16:33 -0400 Subject: [Distutils] Revisiting the "pkginfo" patch In-Reply-To: <3900E675.92B53934@enduden.com>; from Michael Muller on Fri, Apr 21, 2000 at 07:38:29PM -0400 References: <20000420190152.A766@beelzebub> <3900E675.92B53934@enduden.com> Message-ID: <20000421221633.A476@beelzebub> On 21 April 2000, Michael Muller said: > I disagree. Distribution contains package meta-info, but it also contains a > lot of information that is relevant to a source distribution: packages, > modules, source files. PackageInfo includes a subset of that information > (package name, version, author...) and it also includes the final set of > installed files, which appears to me to be the product of the install > commands, not of the Distribution. Well, if you were watching python-checkins@python.org late last night, you'll notice you (partly) won that argument without even trying: I've separated the meta-data out into a DistributionMetadata class, because that was the best way to make Bastian's "meta-data display options" patch work. However, DistributionMetadata is *just* a place for things like the package name, version, author, etc. to live, and for methods to dole those out. Someday, that will include fancy meta-data like dependencies/requirements/compatible versions, but for now it's simple and basic; the only logic is stuff like `return self.name or "UNKNOWN"' in the 'get_name()' method. But I still don't think this is the place for lists-of-files-built or lists-of-file-installed. As it happens, I have made some renovations to the code to accomodate this sort of thing; now, you get those list by calling the 'get_outputs()' method on the build or install command objects. I think the list-of-files-installed really is the property of the class that does the installation, and I don't see a big need to keep a copy of that list with the "package meta-data" -- yes, this is information that should be installed with the meta-data, but it isn't really meta-data per se (IMHO). > Furthermore, package information deserves to be seperated out for purposes of > modularity: if people want to create alternate forms of the module (based, > perhaps, on RPM or DBM files), they should be able to plug their replacement > right into the system as long as they conform to a very simple, specific > interface. Likewise, programmers using alternate build/distribution > technologies should be able to define package information without having to > use distutils. If people want to make RPMs, they will use the "bdist_rpm" command -- when it exists. ;-) A prototype is "bdist_dumb", which generates a zip or tarball built distribution; I'm blithely optimistic that extending that to generate an RPM won't be too hard. Anyways, the "bdist_*" commands will all depend heavily on the 'get_outputs()' method of the "install" command, as well as the meta-data info furnished by the Distribution object (on behalf of its DistributionMetadata object). > The problem is not so much the type checking: it's the persistence. In order > to read and write the package information, we need to either have code to > write and read each field individually, or have some sort of generalized way > of writing and reading different kinds of content. The former approach is > difficult to extend and maintain, particularly when you start dealing with > complex nested structures. Ahh, I thought it was something like that. I'm also starting think your original pprint-and-execfile approach was better. Arghh! Maybe a syntax with fragments of Python code to define the complicated structures would be a good compromise. Hmmm... in any case, I think it's moving away from something simple enough for ConfigParser to be appropriate. Greg -- Greg Ward - geek gward@ase.com http://starship.python.net/~gward/ I just forgot my whole philosophy of life!!! From gward@ase.com Sat Apr 22 04:33:56 2000 From: gward@ase.com (Greg Ward) Date: Fri, 21 Apr 2000 23:33:56 -0400 Subject: [Distutils] ANNOUNCE: Distutils 0.8.1 released Message-ID: <20000421233356.A919@beelzebub> This release fixes a couple of bugs that people reported in Distutils 0.8, as well as adding two nice features. Here's the change log... * added the meta-data display options: now you can run the setup script with --name, --author, --description, etc. and it will print out that information (thanks to Bastian Kleineidam for the original idea and patch) * thoroughly overhauled the distutils.fancy_getopt module to support those options * manifest template files can now take many filename patterns per line (thanks to Andrew Kuchling) * code cleanup: better and more consistent use of exceptions * building extensions should now work on AIX, thanks to a hack that fixes "./ld_so_aix" in Python's installed Makefile * fixed the "sample3" example to actually work (it hadn't been updated with the Great Renaming prior to release 0.8) Greg You'll find at the usual place: http://www.python.org/sigs/distutils-sig/download.html -- Greg Ward - programmer-at-large gward@ase.com http://starship.python.net/~gward/ I'm a nuclear submarine under the polar ice cap and I need a Kleenex! From hgebel@inet.net Sat Apr 22 20:02:26 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Sat, 22 Apr 2000 15:02:26 -0400 Subject: [Distutils] --help not working in 0.8.1 (w/patch) Message-ID: <20000422150226.B13826@inet.net> --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The --help argument is not working in Distutils v0.8.1 . The problem is caused by two things: FancyGetopt.generate_help() does not have a self argument and FancyGetopt.print_help() places the file argument first, but all the functions that call it seem to expect the header argument to be first. A patch is attached that fixes the problem. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses: python binding for ncurses http://pyncurses.sourceforge.net --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="distutils-help.patch" --- fancy_getopt.py.old Sat Apr 22 14:49:01 2000 +++ fancy_getopt.py Sat Apr 22 14:20:50 2000 @@ -304,7 +304,7 @@ return self.option_order - def generate_help (header=None): + def generate_help (self, header=None): """Generate help text (a list of strings, one per suggested line of output) from the option table for this FancyGetopt object.""" @@ -388,7 +388,7 @@ # generate_help () - def print_help (self, file=None, header=None): + def print_help (self, header=None, file=None): if file is None: file = sys.stdout for line in self.generate_help (header): --2oS5YaxWCcQjTEyO-- From hgebel@inet.net Sat Apr 22 20:07:46 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Sat, 22 Apr 2000 15:07:46 -0400 Subject: [Distutils] PyNcurses using Distutils Message-ID: <20000422150746.C13826@inet.net> I thought this would be an appropriate place to mention that the CVS version of PyNcurses now uses Distutils. The next release (which will be in a few days) will also use them. Thanks for the great package, if anybody here uses PyNcurses they can tell you the old method was about as primitive as they come, now with Distutils it makes things look like I know what I'm doing ;) -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses: python binding for ncurses http://pyncurses.sourceforge.net From hgebel@inet.net Sun Apr 23 01:09:00 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Sat, 22 Apr 2000 20:09:00 -0400 Subject: [Distutils] INSTALL file Message-ID: <20000422200900.I13826@inet.net> --VuQYccsttdhdIfIP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I thought some people might find a generic INSTALL file like the one supplied with programs that use ./configure, here is one I prepared that gives a few lines with the most-common-case installation instructions and gives the complete ./setup.py help output. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses: python binding for ncurses http://pyncurses.sourceforge.net --VuQYccsttdhdIfIP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=INSTALL Basic Installation ================== These are generic installation instructions. The simplest way to compile this package is: 1. `cd` to the directory containing the package's source code. 2. Type `./setup.py build` to build the package. 3. Type `su` to become the superuser 4. Type `./setup.py install` to install the module. 5. You can remove the compiled extension modules and other installation related files from the source code directory by typing `./setup clean --all clean`. Operation Controls ================== The 'setup.py' script recognizes the following options to control how it operates: usage: ./setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: ./setup.py --help or: ./setup.py --help-commands or: ./setup.py cmd --help --verbose (-v) run verbosely (default) --quiet (-q) run quietly (turns verbosity off) --dry-run (-n) don't actually do anything --help (-h) show help message --help-commands list all available commands --name print package name --version (-V) print package version --fullname print - --author print the author's name --author-email print the author's email address --maintainer print the maintainer's name --maintainer-email print the maintainer's email address --contact print the name of the maintainer if present, else author --contact-email print the email of the maintainer if present, else author --url print the URL for this package --licence print the licence of the package --license alias for --licence --description print the package description build build everything needed to install --build-base (-b) base directory for build library --build-purelib build directory for platform-neutral distributions --build-platlib build directory for platform-specific distributions --build-lib build directory for all distribution (defaults to either build-purelib or build-platlib --build-temp (-t) temporary build directory --debug (-g) compile extensions and libraries with debugging --force (-f) forcibly build everything (ignore file timestamps build_py "build" pure Python modules (copy to build directory) --build-lib (-d) directory to "build" (copy) to --force (-f) forcibly build everything (ignore file timestamps build_ext build C/C++ extensions (compile/link to build directory) --build-lib (-b) directory for compiled extension modules --build-temp (-t) directory for temporary files (build by-products) --inplace (-i) ignore build-lib and put compiled extensions into the --include-dirs (-I) list of directories to search for header files --define (-D) C preprocessor macros to define --undef (-U) C preprocessor macros to undefine --libraries (-l) external C libraries to link with --library-dirs (-L) directories to search for external C libraries --rpath (-R) directories to search for shared C libraries at runtime --link-objects (-O) extra explicit link objects to include in the link --debug (-g) compile/link with debugging information --force (-f) forcibly build everything (ignore file timestamps build_clib build C/C++ libraries used by Python extensions --build-clib (-b) directory to build C/C++ libraries to --build-temp (-t) directory to put temporary build by-products --debug (-g) compile with debugging information --force (-f) forcibly build everything (ignore file timestamps install install everything from build directory --prefix installation prefix --exec-prefix (Unix only) prefix for platform-specific files --home (Unix only) home directory to install under --install-base base installation directory (instead of --prefix or -- home) --install-platbase base installation directory for platform-specific files (instead of --exec-prefix or --home) --install-purelib installation directory for pure Python module distributions --install-platlib installation directory for non-pure module distributions --install-lib installation directory for all module distributions (overrides --install-purelib and --install-platlib) --install-scripts installation directory for Python scripts --install-data installation directory for data files install_lib install pure Python modules --install-dir (-d) directory to install to --build-dir (-b) build directory (where to install from) --compile (-c) compile .py to .pyc --optimize (-o) compile .py to .pyo (optimized) clean clean up output of 'build' command --build-base (-b) base build directory (default: 'build.build-base') --build-lib build directory for all modules (default: 'build.build- lib') --build-temp (-t) temporary build directory (default: 'build.build-temp') --all (-a) remove all build output, not just temporary by-products sdist create a source distribution (tarball, zip file, etc.) --template (-t) name of manifest template file [default: MANIFEST.in] --manifest (-m) name of manifest file [default: MANIFEST] --use-defaults include the default file set in the manifest [default; disable with --no-defaults] --manifest-only just regenerate the manifest and then stop --force-manifest forcibly regenerate the manifest and carry on as usual --formats formats for source distribution (tar, ztar, gztar, or zip) --keep-tree (-k) keep the distribution tree around after creating archive bdist create a built (binary) distribution --format (-f) format for distribution (tar, ztar, gztar, zip) bdist_dumb create a "dumb" built distribution --format (-f) archive format to create (tar, ztar, gztar, zip) --keep-tree (-k) keep the pseudo-installation tree around after creating --VuQYccsttdhdIfIP-- From gward@ase.com Sun Apr 23 04:20:45 2000 From: gward@ase.com (Greg Ward) Date: Sat, 22 Apr 2000 23:20:45 -0400 Subject: [Distutils] --help not working in 0.8.1 (w/patch) In-Reply-To: <20000422150226.B13826@inet.net>; from Harry Henry Gebel on Sat, Apr 22, 2000 at 03:02:26PM -0400 References: <20000422150226.B13826@inet.net> Message-ID: <20000422232045.A1041@beelzebub> On 22 April 2000, Harry Henry Gebel said: > The --help argument is not working in Distutils v0.8.1 . The problem is > caused by two things: FancyGetopt.generate_help() does not have a self > argument and FancyGetopt.print_help() places the file argument first, but > all the functions that call it seem to expect the header argument to be > first. A patch is attached that fixes the problem. Gaakk! Paper-bag-over-head time. Thanks for the patch -- checked in and a new code snapshot released. I'll see if any more dumb bugs show up in 0.8.1 and then put out 0.8.2. Argghg... BTW, has anyone other than me successfully used the "sdist" command, specifically written and processed a MANIFEST.in file, under Windows yet? Greg -- Greg Ward - geek gward@ase.com http://starship.python.net/~gward/ I am having FUN... I wonder if it's NET FUN or GROSS FUN? From gward@ase.com Sun Apr 23 04:32:11 2000 From: gward@ase.com (Greg Ward) Date: Sat, 22 Apr 2000 23:32:11 -0400 Subject: [Distutils] INSTALL file In-Reply-To: <20000422200900.I13826@inet.net>; from Harry Henry Gebel on Sat, Apr 22, 2000 at 08:09:00PM -0400 References: <20000422200900.I13826@inet.net> Message-ID: <20000422233211.B1041@beelzebub> On 22 April 2000, Harry Henry Gebel said: > I thought some people might find a generic INSTALL file like the one > supplied with programs that use ./configure, here is one I prepared that > gives a few lines with the most-common-case installation instructions and > gives the complete ./setup.py help output. To be honest, I've never been a big fan of the "standard installation instructions" modus operandi. Like the 19k of the GPL, once you've read the 15k of the standard Autconf INSTALL file, it's really just a waste to carry it around everywhere. One way of looking at it is this. There are two kinds of software packages in the world: those that build trivially from source, and those that do not. For those that do, the build/install instructions are this: python setup.py install with a proviso about needing privilege to write to the Python library directory on Unix and a reference to the "Installing Python Modules" manual for detail. For those that do not build trivially, the developer will always have to write custom build/install instructions. In the first case, a separate file devoted to build/install is redundant, since building and installing is painless and trivial, and anyways there's a nice manual to explain the process if you need to do anything out of the ordinary. In the second case, generic build/install instructions are worse than useless, since the poor user has to figure out what parts of the INSTALL file still apply, how to augment that information with information from the README (assuming the developer even bothered to document the peculiarities of his package, which is not always a given), etc. And, as long as I'm bitching... > The simplest way to compile this package is: > > 1. `cd` to the directory containing the package's source code. Not necessarily. Strictly speaking, the source code to the Distutils is in (eg.) Distutils-0.8/distutils, and you need to be in the Distutils-0.8 directory; similarly for NumPy and PyXML, and no doubt many others. The key is: be in the directory where the setup script lives. > 2. Type `./setup.py build` to build the package. This will only work on Unix, and only if the developer chmod +x'd the setup script. (I do this, since I prefer to type "./setup.py" to "python setup.py". But I always document it as "python setup.py", since the standard incantation must be the same on all major platforms.) > 3. Type `su` to become the superuser Again, Unix-specific. > 5. You can remove the compiled extension modules and other installation > related files from the source code directory by typing > `./setup clean --all clean`. Actually, "setup.py clean -a" is enough (-a == --all, of course). But this isn't really relevant, since I think the right thing to do is refer people to the "Installing Python Modules" manual. Greg -- Greg Ward - geek gward@ase.com http://starship.python.net/~gward/ Whatever became of eternal truth? From hgebel@inet.net Sun Apr 23 08:55:25 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Sun, 23 Apr 2000 03:55:25 -0400 Subject: [Distutils] Distutils RPM Message-ID: <20000423035525.M13826@inet.net> I don't know if anyone is interested, but there is are Distutils RPMs available at my FTP site: ftp://pyncurses.sourceforge.net/pub/pyncurses/ Happy Easter! -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From hgebel@inet.net Mon Apr 24 06:33:48 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Mon, 24 Apr 2000 01:33:48 -0400 Subject: [Distutils] PATCH: Expanded tarball abilites Message-ID: <20000424013348.H8616@inet.net> --0NB0lE7sNnW8+0qW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have attached a patch against CVS to expand the functionality of the tarball formats in the sdist and bdist commands. It adds the following: Adds bztar format to generate .tar.bz2 tarballs Uses the -f argument to overright old tarballs automatically, I am assuming that if the old tarball was wanted it would have been moved or else the version number would have been changed. Uses the -9 argument to bzip2 and gzip to use maximum compression. Compress uses the maximum compression by default. Tests for correct value for the 'compress' argument of make_tarball. This is one less place for someone adding new compression programs to forget to change. I have a patch (but not attached) which detects if tar is GNU tar > 1.13, but I do not know if I should submit it because it depends on the Unix-only popen2 module. Can it be assumed that only Unix users will generate tarballs, and if this assumption can be made should I submit the patch? In any case, I don't know very much about tar, so someone else would have to put the information to use after it is detected. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --0NB0lE7sNnW8+0qW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tarballs.patch" ? build ? MANIFEST ? tarballs.patch Index: distutils/archive_util.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/archive_util.py,v retrieving revision 1.2 diff -u -r1.2 archive_util.py --- archive_util.py 2000/04/22 03:09:56 1.2 +++ archive_util.py 2000/04/24 05:28:18 @@ -15,12 +15,12 @@ def make_tarball (base_name, base_dir, compress="gzip", verbose=0, dry_run=0): """Create a (possibly compressed) tar file from all the files under - 'base_dir'. 'compress' must be "gzip" (the default), "compress", or - None. Both "tar" and the compression utility named by 'compress' - must be on the default program search path, so this is probably - Unix-specific. The output tar file will be named 'base_dir' + - ".tar", possibly plus the appropriate compression extension - (".gz" or ".Z"). Return the output filename.""" + 'base_dir'. 'compress' must be "gzip" (the default), "compress", + "bzip2", or None. Both "tar" and the compression utility named by + 'compress' must be on the default program search path, so this is + probably Unix-specific. The output tar file will be named 'base_dir' + + ".tar", possibly plus the appropriate compression extension (".gz", + ".bz2" or ".Z"). Return the output filename.""" # XXX GNU tar 1.13 has a nifty option to add a prefix directory. # It's pretty new, though, so we certainly can't require it -- @@ -29,9 +29,15 @@ # detect GNU tar to use its 'z' option and save a step.) compress_ext = { 'gzip': ".gz", + 'bzip2': '.bz2' 'compress': ".Z" } + + # flags for compression program, each element of list will be an argument + compress_flags = {'gzip': ["-f9"], + 'compress': ["-f"], + 'bzip2': ['-f9']} - if compress is not None and compress not in ('gzip', 'compress'): + if compress is not None and compress not in compress_ext.keys(): raise ValueError, \ "bad value for 'compress': must be None, 'gzip', or 'compress'" @@ -40,7 +46,8 @@ spawn (cmd, verbose=verbose, dry_run=dry_run) if compress: - spawn ([compress, archive_name], verbose=verbose, dry_run=dry_run) + spawn ([compress] + compress_flags[compress] + [archive_name], + verbose=verbose, dry_run=dry_run) return archive_name + compress_ext[compress] else: return archive_name @@ -104,6 +111,7 @@ ARCHIVE_FORMATS = { 'gztar': (make_tarball, [('compress', 'gzip')]), + 'bztar': (make_tarball, [('compress', 'bzip2')]), 'ztar': (make_tarball, [('compress', 'compress')]), 'tar': (make_tarball, [('compress', None)]), 'zip': (make_zipfile, []) Index: distutils/command/bdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/bdist.py,v retrieving revision 1.4 diff -u -r1.4 bdist.py --- bdist.py 2000/03/31 05:21:27 1.4 +++ bdist.py 2000/04/24 05:28:19 @@ -18,7 +18,8 @@ description = "create a built (binary) distribution" user_options = [('format=', 'f', - "format for distribution (tar, ztar, gztar, zip, ... )"), + "format for distribution " + + "(tar, ztar, gztar, bztar, zip, ... )"), ] # This won't do in reality: will need to distinguish RPM-ish Linux, @@ -27,6 +28,7 @@ 'nt': 'zip', } format_command = { 'gztar': 'bdist_dumb', + 'bztar': 'bdist_dumb', 'ztar': 'bdist_dumb', 'tar': 'bdist_dumb', 'zip': 'bdist_dumb', } Index: distutils/command/sdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/sdist.py,v retrieving revision 1.15 diff -u -r1.15 sdist.py --- sdist.py 2000/04/22 03:11:55 1.15 +++ sdist.py 2000/04/24 05:28:23 @@ -33,9 +33,8 @@ "just regenerate the manifest and then stop"), ('force-manifest', None, "forcibly regenerate the manifest and carry on as usual"), - ('formats=', None, - "formats for source distribution (tar, ztar, gztar, or zip)"), + "formats for source distribution (tar, ztar, gztar, bztar, or zip)"), ('keep-tree', 'k', "keep the distribution tree around after creating " + "archive file(s)"), --0NB0lE7sNnW8+0qW-- From hgebel@inet.net Mon Apr 24 10:15:03 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Mon, 24 Apr 2000 05:15:03 -0400 Subject: [Distutils] Patch again (sorry) Message-ID: <20000424051502.I8616@inet.net> --++alDQ2ROsODg1x+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline When I tested the bzip2 patch I had bzip after compress, but when I made the patch I switched them and I forgot to but a comma after bzip2, this patch has the comma. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --++alDQ2ROsODg1x+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tarballs.patch" ? build ? MANIFEST ? tarballs.patch Index: distutils/archive_util.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/archive_util.py,v retrieving revision 1.2 diff -u -r1.2 archive_util.py --- archive_util.py 2000/04/22 03:09:56 1.2 +++ archive_util.py 2000/04/24 08:42:59 @@ -15,12 +15,12 @@ def make_tarball (base_name, base_dir, compress="gzip", verbose=0, dry_run=0): """Create a (possibly compressed) tar file from all the files under - 'base_dir'. 'compress' must be "gzip" (the default), "compress", or - None. Both "tar" and the compression utility named by 'compress' - must be on the default program search path, so this is probably - Unix-specific. The output tar file will be named 'base_dir' + - ".tar", possibly plus the appropriate compression extension - (".gz" or ".Z"). Return the output filename.""" + 'base_dir'. 'compress' must be "gzip" (the default), "compress", + "bzip2", or None. Both "tar" and the compression utility named by + 'compress' must be on the default program search path, so this is + probably Unix-specific. The output tar file will be named 'base_dir' + + ".tar", possibly plus the appropriate compression extension (".gz", + ".bz2" or ".Z"). Return the output filename.""" # XXX GNU tar 1.13 has a nifty option to add a prefix directory. # It's pretty new, though, so we certainly can't require it -- @@ -29,9 +29,15 @@ # detect GNU tar to use its 'z' option and save a step.) compress_ext = { 'gzip': ".gz", + 'bzip2': '.bz2', 'compress': ".Z" } + + # flags for compression program, each element of list will be an argument + compress_flags = {'gzip': ["-f9"], + 'compress': ["-f"], + 'bzip2': ['-f9']} - if compress is not None and compress not in ('gzip', 'compress'): + if compress is not None and compress not in compress_ext.keys(): raise ValueError, \ "bad value for 'compress': must be None, 'gzip', or 'compress'" @@ -40,7 +46,8 @@ spawn (cmd, verbose=verbose, dry_run=dry_run) if compress: - spawn ([compress, archive_name], verbose=verbose, dry_run=dry_run) + spawn ([compress] + compress_flags[compress] + [archive_name], + verbose=verbose, dry_run=dry_run) return archive_name + compress_ext[compress] else: return archive_name @@ -104,6 +111,7 @@ ARCHIVE_FORMATS = { 'gztar': (make_tarball, [('compress', 'gzip')]), + 'bztar': (make_tarball, [('compress', 'bzip2')]), 'ztar': (make_tarball, [('compress', 'compress')]), 'tar': (make_tarball, [('compress', None)]), 'zip': (make_zipfile, []) Index: distutils/command/bdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/bdist.py,v retrieving revision 1.4 diff -u -r1.4 bdist.py --- bdist.py 2000/03/31 05:21:27 1.4 +++ bdist.py 2000/04/24 08:43:00 @@ -18,7 +18,8 @@ description = "create a built (binary) distribution" user_options = [('format=', 'f', - "format for distribution (tar, ztar, gztar, zip, ... )"), + "format for distribution " + + "(tar, ztar, gztar, bztar, zip, ... )"), ] # This won't do in reality: will need to distinguish RPM-ish Linux, @@ -27,6 +28,7 @@ 'nt': 'zip', } format_command = { 'gztar': 'bdist_dumb', + 'bztar': 'bdist_dumb', 'ztar': 'bdist_dumb', 'tar': 'bdist_dumb', 'zip': 'bdist_dumb', } Index: distutils/command/sdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/sdist.py,v retrieving revision 1.15 diff -u -r1.15 sdist.py --- sdist.py 2000/04/22 03:11:55 1.15 +++ sdist.py 2000/04/24 08:43:03 @@ -33,9 +33,8 @@ "just regenerate the manifest and then stop"), ('force-manifest', None, "forcibly regenerate the manifest and carry on as usual"), - ('formats=', None, - "formats for source distribution (tar, ztar, gztar, or zip)"), + "formats for source distribution (tar, ztar, gztar, bztar, or zip)"), ('keep-tree', 'k', "keep the distribution tree around after creating " + "archive file(s)"), --++alDQ2ROsODg1x+-- From hgebel@inet.net Mon Apr 24 10:19:02 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Mon, 24 Apr 2000 05:19:02 -0400 Subject: [Distutils] Little tiny patch Message-ID: <20000424051902.J8616@inet.net> --rfwNdt5cNUUjB/69 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This correct a small error in the distutils.core.setup docstring where it refers to class Distribution as still being in distutils.core . -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --rfwNdt5cNUUjB/69 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="setup-doc.patch" ? build ? MANIFEST ? tarballs.patch ? setup-doc.patch Index: distutils/core.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/core.py,v retrieving revision 1.32 diff -u -r1.32 core.py --- core.py 2000/04/22 03:20:49 1.32 +++ core.py 2000/04/24 09:15:23 @@ -36,9 +36,9 @@ The Distribution instance might be an instance of a class supplied via the 'distclass' keyword argument to 'setup'; if no - such class is supplied, then the 'Distribution' class (also in - this module) is instantiated. All other arguments to 'setup' - (except for 'cmdclass') are used to set attributes of the + such class is supplied, then the 'Distribution' class (found in + module distutils.dist) is instantiated. All other arguments to + 'setup' (except for 'cmdclass') are used to set attributes of the Distribution instance. The 'cmdclass' argument, if supplied, is a dictionary mapping --rfwNdt5cNUUjB/69-- From jlj@cfdrc.com Mon Apr 24 16:00:41 2000 From: jlj@cfdrc.com (Lyle Johnson) Date: Mon, 24 Apr 2000 10:00:41 -0500 Subject: [Distutils] Re: --help not working in 0.8.1 (w/patch) In-Reply-To: <20000423160014.899E51CDC8@dinsdale.python.org> Message-ID: <000c01bfadfd$db8dfcf0$4e574dc0@coltrane.cfdrc.com> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BFADD3.F2B7F4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > BTW, has anyone other than me successfully used the "sdist" command, > specifically written and processed a MANIFEST.in file, under Windows > yet? Looks like there's a bug in the native_path() function and that's why the forward-slashes in commands like this: include/autotest.py don't get translated into Windows-style paths like this: include\autotest.py I think once you look at the current implementation of native_path() you'll see the problem; but I've attached a patch which I think does what you originally intended there. Hope this helps, Lyle ------=_NextPart_000_000D_01BFADD3.F2B7F4F0 Content-Type: text/plain; name="diffs.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="diffs.txt" Index: distutils/util.py =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /projects/cvsroot/distutils/distutils/util.py,v retrieving revision 1.29 diff -a -u -r1.29 util.py --- util.py 2000/04/22 15:14:58 1.29 +++ util.py 2000/04/24 15:01:35 @@ -72,13 +72,13 @@ raise ValueError, "path '%s' cannot be absolute" % pathname if pathname[-1] =3D=3D '/': raise ValueError, "path '%s' cannot end with '/'" % pathname - if os.sep !=3D '/' and os.sep in pathname: - raise ValueError, \ - "path '%s' cannot contain '%c' character" % \ - (pathname, os.sep) - - paths =3D string.split (pathname, '/') - return apply (os.path.join, paths) + if os.sep !=3D '/': + if os.sep in pathname: + raise ValueError, \ + "path '%s' cannot contain '%c' character" % (pathname, = os.sep) + else: + paths =3D string.split (pathname, '/') + return apply (os.path.join, paths) else: return pathname ------=_NextPart_000_000D_01BFADD3.F2B7F4F0-- From hgebel@inet.net Mon Apr 24 18:27:59 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Mon, 24 Apr 2000 13:27:59 -0400 Subject: [Distutils] bdist_rpm Message-ID: <20000424132759.A27307@inet.net> Would I be stepping on any toes if I posted a bdist_rpm patch? I am writing one as an exercise in learning Distutils internal functions, but I don't know if someone else is already working on an official version. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From mmuller@enduden.com Tue Apr 25 01:45:20 2000 From: mmuller@enduden.com (Michael Muller) Date: Mon, 24 Apr 2000 20:45:20 -0400 Subject: [Distutils] Revisiting the "pkginfo" patch Message-ID: <200004250045.UAA28093@bogus.com> Greg Ward wrote: [snip] > But I still don't think this is the place for lists-of-files-built or > lists-of-file-installed. As it happens, I have made some renovations to > the code to accomodate this sort of thing; now, you get those list by > calling the 'get_outputs()' method on the build or install command > objects. I think the list-of-files-installed really is the property of > the class that does the installation, and I don't see a big need to keep > a copy of that list with the "package meta-data" -- yes, this is > information that should be installed with the meta-data, but it isn't > really meta-data per se (IMHO). Perhaps we're quibbling over semantics here: my definition of meta-data is "information about the package that is installed with the package", in other words, DistributionMetadata + the installed file list. Since we both seem to agree that all of this information should be installed with the package, maybe we should use another term to describe this complete set. Anyway, this is what PackageInfo attempts to address. [snip] > If people want to make RPMs, they will use the "bdist_rpm" command -- > when it exists. ;-) A prototype is "bdist_dumb", which generates a zip True, and I suppose that if you're using RPMs, you would just use the RPM command or one of it's many fine graphical wrappers to deal with the RPM database. However, I still maintain that is is desirable to have a single interface that can be specialized to whatever package information repository is preferred by the system administrator. Consider the case where I have a number of packages installed using RPM. Now I download a source release and use (some future version of) the distutils "install" command. Shouldn't "install" be able to determine whether its dependencies are satisfied from the RPM packages as well as its own? I'm not saying that we should implement an RPM front end, just that the interface should be clean and independent enough so that it could _wrap_ an RPM interface. [snip] > Ahh, I thought it was something like that. I'm also starting think your > original pprint-and-execfile approach was better. Arghh! Maybe a :-). Well, I still have the original code... Maybe the best way to prove a point is to implement the alternative. > syntax with fragments of Python code to define the complicated > structures would be a good compromise. Hmmm... in any case, I think > it's moving away from something simple enough for ConfigParser to be > appropriate. Actually, I was thinking about something along these lines Friday night while looking through the funky python-to-english code in the last patch. The hybrid you've suggested might look something like this: if is_trivial_string(item): print '%s: %s' % (attr, item) else: print '%s: ', pprint.pprint(item) Parsing then just becomes a matter of checking for any special characters at the beginning of the value (quote, bracket...). Numbers might cause a problem. You could define a trivial string to exclude strings that begin with a number, but then what about version numbers? Should they have to be quoted? Maybe there should just be a special quoting character around everything but a trivial string. But alas, I'm rambling... ============================================================================= michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- The natural progress of things is for liberty to yield and government to gain control. - Thomas Jefferson ============================================================================= From gward@ase.com Tue Apr 25 02:22:35 2000 From: gward@ase.com (Greg Ward) Date: Mon, 24 Apr 2000 21:22:35 -0400 Subject: [Distutils] Re: --help not working in 0.8.1 (w/patch) In-Reply-To: <000c01bfadfd$db8dfcf0$4e574dc0@coltrane.cfdrc.com>; from Lyle Johnson on Mon, Apr 24, 2000 at 10:00:41AM -0500 References: <20000423160014.899E51CDC8@dinsdale.python.org> <000c01bfadfd$db8dfcf0$4e574dc0@coltrane.cfdrc.com> Message-ID: <20000424212235.B584@beelzebub> On 24 April 2000, Lyle Johnson said: > Looks like there's a bug in the native_path() function and that's why the > forward-slashes in commands like this: [...] > I think once you look at the current implementation of native_path() you'll > see the problem; but I've attached a patch which I think does what you > originally intended there. A-ha! Actually, I probably would never have noticed that -- it's one of those colossally stupid bugs that are instantly obvious to a second pair of eyeballs, but never to the original programmer (at least if the original programmer was me). Debugging is indeed parallelizable. Thanks a bunch -- patch fixed, checked in, and Distutils 0.8.2 will be out shortly. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ In space, no one can hear you fart. From gward@ase.com Tue Apr 25 02:33:46 2000 From: gward@ase.com (Greg Ward) Date: Mon, 24 Apr 2000 21:33:46 -0400 Subject: [Distutils] Current docs online Message-ID: <20000424213346.A654@beelzebub> Hi all -- I finally found one of those round tuits and put the current documentation, processed into PDF and PostScript, online: http://www.python.org/sigs/distutils-sig/doc/ HTML to come. Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ I want to so HAPPY, the VEINS in my neck STAND OUT!! From gward@ase.com Tue Apr 25 02:41:36 2000 From: gward@ase.com (Greg Ward) Date: Mon, 24 Apr 2000 21:41:36 -0400 Subject: [Distutils] PATCH: Expanded tarball abilites In-Reply-To: <20000424013348.H8616@inet.net>; from Harry Henry Gebel on Mon, Apr 24, 2000 at 01:33:48AM -0400 References: <20000424013348.H8616@inet.net> Message-ID: <20000424214136.A633@beelzebub> On 24 April 2000, Harry Henry Gebel said: > I have attached a patch against CVS to expand the functionality of the > tarball formats in the sdist and bdist commands. It adds the following: Cool, thanks! Just checked it in. Great, now at least 0.8.2 has more reasons to exist than my paper-bag-over-head bugs. > I have a patch (but not attached) which detects if tar is GNU tar > 1.13, > but I do not know if I should submit it because it depends on the > Unix-only popen2 module. Can it be assumed that only Unix users will > generate tarballs, and if this assumption can be made should I submit the > patch? In any case, I don't know very much about tar, so someone else > would have to put the information to use after it is detected. Cool, send it in. Easy solution to the portability problem: if hasattr (os, "pipe"): # use popen2 to detect GNU tar 1.13 else: # assume primitive tar Did you finish the job and hack up "sdist" to use the new base dir option (whatever it is)? If not, go ahead and submit just the detect patch -- optionally eliminating the build-tree-of-hard-links step really should be a distinct patch. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ I have many CHARTS and DIAGRAMS ... From gward@ase.com Tue Apr 25 02:54:12 2000 From: gward@ase.com (Greg Ward) Date: Mon, 24 Apr 2000 21:54:12 -0400 Subject: [Distutils] bdist_rpm In-Reply-To: <20000424132759.A27307@inet.net>; from Harry Henry Gebel on Mon, Apr 24, 2000 at 01:27:59PM -0400 References: <20000424132759.A27307@inet.net> Message-ID: <20000424215412.B633@beelzebub> On 24 April 2000, Harry Henry Gebel said: > Would I be stepping on any toes if I posted a bdist_rpm patch? I am > writing one as an exercise in learning Distutils internal functions, but I > don't know if someone else is already working on an official version. Hey, step on any toes you like. I'll be ever so *slightly* peeved, because this means I'll have to learn about Wise or Debian or some other packaging/installer system in order to get any credit for generating smart built distributions. But I'll get over it in oh, about 20 seconds. BTW, here's the interface I had in mind for bdist_rpm: Basic incantation to build a binary RPM: setup.py bdist --format=rpm # creates binary RPM OR setup.py bdist_rpm To build a source RPM: setup.py bdist --format=srpm OR setup.py bdist_rpm --source Any RPM-specific options should be supplied to bdist_rpm, ie. if you want to do anything out of the ordinary, you need to run bdist_rpm, rather than "bdist --format={rpm,srpm}". There should be a "--arch" ("--plat"?) option to "build_rpm" to let people specify the RPM architecture string; it should default to the result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u"). Some rules/heuristics/hacks: * if not self.distribution.has_ext_modules(): use "noarch" for the architecture specification in the RPM MAYBE: * if util.get_platform() =~ /linux-i\d86/: use "i386" for the architecture specification in the RPM The latter strikes me as vaguely ugly, but it will make life easier for people generating RPMs for i86 Linux boxen. Perhaps a similar hack should be done for the other major Linux platforms, eg. Alpha, SPARC, PPC, ...? I dunno what Red Hat's convention for naming RPMs on those platforms is; I'm not entirely sure we should follow Red Hat's lead here (what do Mandrake and SuSE use for architecture strings in RPM filenames?). One idea that has bounced around in my head is to have a "--cheat" or "--nasty" option which skips the whole RPM machinery and just creates the damn binary RPM. This is purely a speed optimization, and not something that would save a lot of time overall, so feel free to ignore me (or accuse me of smoking something weird, etc.). Might require direct access to librpm.a, which is a no-no: I don't want Distutils to rely on any extensions apart from string, re, os, and sys. And finally, these are just ideas -- feel free to implement whatever seems right/natural/logical. Thanks a bunch! Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Money is a powerful aphrodisiac. But flowers work almost as well. From gward@ase.com Tue Apr 25 04:16:16 2000 From: gward@ase.com (Greg Ward) Date: Mon, 24 Apr 2000 23:16:16 -0400 Subject: [Distutils] Distutils 0.8.2 released Message-ID: <20000424231616.A827@beelzebub> Right, as threatened, I've checked in fixes to those two paper-bag-over-my-head bugs, as well as the new bztar feature, and release Distutils 0.8.2. Hey wow, that's cool -- technically speaking, I didn't have to write *any* code for this release -- just check in patches! Thanks, Lyle and Harry! Here's the entry from CHANGES.txt: Release 0.8.2 (24 April, 2000): ------------------------------- * bug fix: --help option failed due to over-eager refactoring in 0.8.1 (thanks to Harry Henry Gebel) * bug fix: conversion of Unix-style paths to Windows style fixed (so the sdist command should be portable now) (thanks to Lyle Johnson) * added bztar format to generate .tar.bz2 source distributions (thanks to Harry Henry Gebel) -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ I can never remember how to spell "mnemonic". From hgebel@inet.net Tue Apr 25 04:58:54 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Mon, 24 Apr 2000 23:58:54 -0400 Subject: [Distutils] PATCH: Expanded tarball abilites In-Reply-To: <20000424214136.A633@beelzebub>; from gward@ase.com on Mon, Apr 24, 2000 at 09:41:36PM -0400 References: <20000424013348.H8616@inet.net> <20000424214136.A633@beelzebub> Message-ID: <20000424235853.C27307@inet.net> > if hasattr (os, "pipe"): > # use popen2 to detect GNU tar 1.13 > else: > # assume primitive tar > > Did you finish the job and hack up "sdist" to use the new base dir > option (whatever it is)? If not, go ahead and submit just the detect > patch -- optionally eliminating the build-tree-of-hard-links step really > should be a distinct patch. > > Greg > The patch was a washout, it didn't save any time and made the code harder to understand. I liked it at two in the morning, but after looking at it when I was wide awake I think the current way is better. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From hgebel@inet.net Tue Apr 25 05:07:15 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 00:07:15 -0400 Subject: [Distutils] bdist_rpm In-Reply-To: <20000424215412.B633@beelzebub>; from gward@ase.com on Mon, Apr 24, 2000 at 09:54:12PM -0400 References: <20000424132759.A27307@inet.net> <20000424215412.B633@beelzebub> Message-ID: <20000425000715.D27307@inet.net> > > Hey, step on any toes you like. I'll be ever so *slightly* peeved, > because this means I'll have to learn about Wise or Debian or some other > packaging/installer system in order to get any credit for generating > smart built distributions. But I'll get over it in oh, about 20 > seconds. Okay, I hope to have a working system ready tonight for simple cases (of which both the Distutils themselves and PyNcurses are examples) probably no options in the initial version, more as I get more practice with Distutils internals. Also, this morning I added two options to the 'install' command specifically for use inside RPM spec files, I will include them in the rpm patch w/ more details. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From fdrake@acm.org Tue Apr 25 05:12:56 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 25 Apr 2000 00:12:56 -0400 (EDT) Subject: [Distutils] bdist_rpm In-Reply-To: <20000424215412.B633@beelzebub> References: <20000424132759.A27307@inet.net> <20000424215412.B633@beelzebub> Message-ID: <14597.6984.460707.176371@seahag.cnri.reston.va.us> Greg Ward writes: > Any RPM-specific options should be supplied to bdist_rpm, ie. if you > want to do anything out of the ordinary, you need to run bdist_rpm, > rather than "bdist --format={rpm,srpm}". Sounds like a reasonable plan. > There should be a "--arch" ("--plat"?) option to "build_rpm" to let > people specify the RPM architecture string; it should default to the > result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u"). Why? > Some rules/heuristics/hacks: > * if not self.distribution.has_ext_modules(): > use "noarch" for the architecture specification in the RPM > > MAYBE: > * if util.get_platform() =~ /linux-i\d86/: > use "i386" for the architecture specification in the RPM > > The latter strikes me as vaguely ugly, but it will make life easier for > people generating RPMs for i86 Linux boxen. Perhaps a similar hack It seems that for each util.get_platform() there will be a single value; these can simply be cataloged and a dictionary containing the mapping stored in the sources (it's not a large dictionary!). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From hgebel@inet.net Tue Apr 25 09:03:07 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 04:03:07 -0400 Subject: [Distutils] patch to make write_manifest respect dry_run Message-ID: <20000425040307.E27307@inet.net> --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a patch that causes sdist.write_manifest() to respect the value of dry_run. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dry_run.patch" Index: distutils/command/sdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/sdist.py,v retrieving revision 1.16 diff -u -r1.16 sdist.py --- sdist.py 2000/04/25 01:38:20 1.16 +++ sdist.py 2000/04/25 08:01:34 @@ -11,7 +11,8 @@ from types import * from glob import glob from distutils.core import Command -from distutils.util import newer, create_tree, remove_tree, native_path +from distutils.util import newer, create_tree, remove_tree, native_path, \ + write_file from distutils.archive_util import check_archive_formats from distutils.text_file import TextFile from distutils.errors import DistutilsExecError, DistutilsOptionError @@ -447,10 +448,9 @@ by 'find_defaults()' and 'read_template()') to the manifest file named by 'self.manifest'.""" - manifest = open (self.manifest, "w") - for fn in self.files: - manifest.write (fn + '\n') - manifest.close () + self.execute(write_file, + (self.manifest, self.files), + "Writing manifest file") # write_manifest () --ADZbWkCsHQ7r3kzd-- From hgebel@inet.net Tue Apr 25 10:04:30 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 05:04:30 -0400 Subject: [Distutils] Just an idea Message-ID: <20000425050430.G27307@inet.net> Just an idea for generating both .pyc and .pyo byte code: have a new command that just generates byte code in an already installed set of files, (perhaps `setup.py compile_only`), then spawn python -o setup.py compile_only from within `setup.py install` -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From calvin@cs.uni-sb.de Tue Apr 25 10:19:48 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Tue, 25 Apr 2000 11:19:48 +0200 (CEST) Subject: [Distutils] How to build Debian packages (answer) Message-ID: Hello, heres is the thing I do to build Debian packages: [Makefile snippet] install: ./setup.py install --prefix=/tmp/usr --exec-prefix=/tmp/usr cp -a /tmp/usr/* $(DESTIDR)/usr # install misc additional files install -c -m 755 linkchecker $(DESTDIR)/usr/bin ... Yes, its a hack, but it works. Bastian -- Bastian Kleineidam -- Debian Linux bug squasher .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^ From hgebel@inet.net Tue Apr 25 10:29:16 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 05:29:16 -0400 Subject: [Distutils] Patch for new install options Message-ID: <20000425052916.H27307@inet.net> --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It doesn't look like I will be done with bdist_rpm tonight, here is the patch for the now install options; they are both intended to be run by RPM or other packaging systems from within a .spec file (or equivalent) (although the RPM process may have been launched by another setup.py) Some things I would like different: A better name for the file containing a list of installed files, or change it to allow a file to be specified as part of the option. Better help strings (I'm not good at help strings) Mac and Windows support for --package-prefix, I didn't implement them because I don't know the proper format for Windows and Mac paths to put in INSTALL_SCHEME . Is there a better way than using glob() to get a list of compiled byte-code files? I know glob() is available in Windows Python because I used it in a script I wrote for a friend of mine, but is it available in Mac Python? -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="install_options.patch" Index: distutils/command/install.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/install.py,v retrieving revision 1.21 diff -u -r1.21 install.py --- install.py 2000/03/31 02:52:02 1.21 +++ install.py 2000/04/25 09:21:08 @@ -11,6 +11,7 @@ from distutils.core import Command from distutils.util import write_file, native_path, subst_vars from distutils.errors import DistutilsOptionError +from glob import glob INSTALL_SCHEMES = { 'unix_prefix': { @@ -19,6 +20,12 @@ 'scripts': '$base/bin', 'data' : '$base/share', }, + 'unix_package_prefix': { + 'purelib': '$root/$base/lib/python$py_version_short/site-packages', + 'platlib': '$root/$platbase/lib/python$py_version_short/site-packages', + 'scripts': '$root/$base/bin', + 'data' : '$root/$base/share', + }, 'unix_home': { 'purelib': '$base/lib/python', 'platlib': '$base/lib/python', @@ -53,6 +60,11 @@ ('home=', None, "(Unix only) home directory to install under"), + # treats package prefix like root directory + ('package-prefix=', None, + "(For use by packaging systems) prefix is treated like " \ + "root directory"), + # Or, just set the base director(y|ies) ('install-base=', None, "base installation directory (instead of --prefix or --home)"), @@ -79,6 +91,9 @@ #('install-man=', None, "directory for Unix man pages"), #('install-html=', None, "directory for HTML documentation"), #('install-info=', None, "directory for GNU info files"), + + ('record-install', None, + "make a record of installation") ] @@ -113,6 +128,7 @@ self.install_lib = None # set to either purelib or platlib self.install_scripts = None self.install_data = None + self.package_prefix = None # will be prepended to any other dirs # These two are for putting non-packagized distributions into their # own directory and creating a .pth file if it makes sense. @@ -137,6 +153,7 @@ #self.install_html = None #self.install_info = None + self.record_install = None def finalize_options (self): @@ -166,6 +183,9 @@ raise DistutilsOptionError, \ ("must supply either home or prefix/exec-prefix -- " + "not both") + if self.home and self.package_prefix: + raise DistutilsOptionError, \ + ("cannot supply both home and package prefix") else: if self.exec_prefix: self.warn ("exec-prefix option ignored on this platform") @@ -173,6 +193,9 @@ if self.home: self.warn ("home option ignored on this platform") self.home = None + if self.package_prefix: # for now + self.warn ("package-prefix option ignored on this platform") + self.package_prefix = None # Now the interesting logic -- so interesting that we farm it out # to other methods. The goal of these methods is to set the final @@ -263,7 +286,10 @@ self.install_base = self.prefix self.install_platbase = self.exec_prefix - self.select_scheme ("unix_prefix") + if self.package_prefix: + self.select_scheme("unix_package_prefix") + else: + self.select_scheme ("unix_prefix") # finalize_unix () @@ -300,6 +326,7 @@ vars = { 'base': self.install_base, 'platbase': self.install_platbase, + 'root': self.package_prefix, 'py_version_short': sys.version[0:3], } @@ -379,6 +406,22 @@ "Python's module search path (sys.path) -- " + "you'll have to change the search path yourself") % self.install_lib) + + # write list of installed files, if requested. + if self.record_install: + outputs = self.get_outputs() + for counter in xrange (len (outputs)): # include ".pyc" and ".pyo" + if outputs[counter][-3:] == ".py": + byte_code = glob(outputs[counter] + '[co]') + outputs.extend(byte_code) + outputs.sort() # just makes it look nicer + if self.package_prefix: # strip any package prefix + prefix_len = len(self.package_prefix) + 1 + for counter in xrange (len (outputs)): + outputs[counter] = outputs[counter][prefix_len:] + self.execute(write_file, + ("INSTALLED_FILES", outputs), + "Writing list of installed files") # run () --YD3LsXFS42OYHhNZ-- From hgebel@inet.net Tue Apr 25 10:53:49 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 05:53:49 -0400 Subject: [Distutils] New metadata patch Message-ID: <20000425055349.J27307@inet.net> --mR8QP4gmHujQHb1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a patch to add a new item to class DistributionMetadata , long_description. Most of the info for RPMs I am putting in a separate file, but this seemed appropriate for inclusion in setup.py, it would be useful, for example, for adding an option to create .lsm files. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --mR8QP4gmHujQHb1c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="long_description.patch" Index: distutils/dist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/dist.py,v retrieving revision 1.7 diff -u -r1.7 dist.py --- dist.py 2000/04/22 02:52:44 1.7 +++ dist.py 2000/04/25 09:48:47 @@ -89,6 +89,8 @@ "alias for --licence"), ('description', None, "print the package description"), + ('long-description', None, + "print the long package description"), ] display_option_names = map(lambda x: string.translate(x[0], longopt_xlate), display_options) @@ -638,6 +640,7 @@ self.url = None self.licence = None self.description = None + self.long_description = None # -- Metadata query methods ---------------------------------------- @@ -680,7 +683,10 @@ def get_description(self): return self.description or "UNKNOWN" - + + def get_long_description(self): + return self.long_description or "UNKNOWN" + # class DistributionMetadata if __name__ == "__main__": --mR8QP4gmHujQHb1c-- From hgebel@inet.net Tue Apr 25 14:23:38 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 09:23:38 -0400 Subject: [Distutils] patch for bdist_dumb Message-ID: <20000425092338.A29766@inet.net> --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a patch to bdist_dumb to keep it from raising a NameErrer when it tries to raise a DistutilsPlatformError . -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="exeception_error.patch" Index: distutils/command/bdist_dumb.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/bdist_dumb.py,v retrieving revision 1.3 diff -u -r1.3 bdist_dumb.py --- bdist_dumb.py 2000/04/22 02:51:25 1.3 +++ bdist_dumb.py 2000/04/25 13:19:42 @@ -11,6 +11,7 @@ import os from distutils.core import Command from distutils.util import get_platform, create_tree, remove_tree +from distutils.errors import * class bdist_dumb (Command): --C7zPtVaVf+AK4Oqc-- From mwa@gate.net Tue Apr 25 15:04:26 2000 From: mwa@gate.net (Mark W. Alexander) Date: Tue, 25 Apr 2000 10:04:26 -0400 (EDT) Subject: [Distutils] Current docs online In-Reply-To: <20000424213346.A654@beelzebub> Message-ID: Wow! I just needed this today! Anyway, I have been off this list for some time due to prioritus interuptus and just pulled distutils yesterday to see how things are going. Things are looking real good, and you all are to be congratulated. I'll try to stick around for a while and help now that almost everything's done ;-) Mark Alexander mwa@gate.net On Mon, 24 Apr 2000, Greg Ward wrote: > Date: Mon, 24 Apr 2000 21:33:46 -0400 > From: Greg Ward > To: distutils-sig@python.org > Subject: [Distutils] Current docs online > > Hi all -- > > I finally found one of those round tuits and put the current > documentation, processed into PDF and PostScript, online: > > http://www.python.org/sigs/distutils-sig/doc/ > > HTML to come. > > Greg > -- > Greg Ward - just another Python hacker gward@python.net > http://starship.python.net/~gward/ > I want to so HAPPY, the VEINS in my neck STAND OUT!! > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig > From hgebel@inet.net Tue Apr 25 15:59:56 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Tue, 25 Apr 2000 10:59:56 -0400 Subject: [Distutils] bdist_rpm Message-ID: <20000425105956.B29766@inet.net> I'm done with bdist_rpm, I will post it tonight with instructions after I get some sleep and test it. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From gward@ase.com Wed Apr 26 01:51:32 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 20:51:32 -0400 Subject: [Distutils] PATCH: Expanded tarball abilites In-Reply-To: <20000424235853.C27307@inet.net>; from Harry Henry Gebel on Mon, Apr 24, 2000 at 11:58:54PM -0400 References: <20000424013348.H8616@inet.net> <20000424214136.A633@beelzebub> <20000424235853.C27307@inet.net> Message-ID: <20000425205132.A465@beelzebub> On 24 April 2000, Harry Henry Gebel said: > The patch was a washout, it didn't save any time and made the code harder to > understand. I liked it at two in the morning, but after looking at it when > I was wide awake I think the current way is better. Okee-dokey. If anyone's interested, it would still be mildly interesting and useful to detect GNU tar and use the -z option, and to detect GNU tar >= 1.13 and use the "base directory" option. Not essential, but it's one of those things that makes the Distutils look smarter, so I like it. ;-) Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ Don't hate yourself in the morning -- sleep till noon. From gward@ase.com Wed Apr 26 02:00:56 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 21:00:56 -0400 Subject: [Distutils] bdist_rpm In-Reply-To: <14597.6984.460707.176371@seahag.cnri.reston.va.us>; from Fred L. Drake, Jr. on Tue, Apr 25, 2000 at 12:12:56AM -0400 References: <20000424132759.A27307@inet.net> <20000424215412.B633@beelzebub> <14597.6984.460707.176371@seahag.cnri.reston.va.us> Message-ID: <20000425210056.B465@beelzebub> On 25 April 2000, Fred L. Drake, Jr. said: > > There should be a "--arch" ("--plat"?) option to "build_rpm" to let > > people specify the RPM architecture string; it should default to the > > result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u"). > > Why? Because the convention, at least in Red Hat-land, is that RPMs for Linux on the Intel x86 platform are named like "foo-1.23-1.i386.rpm" or "bar-3.21-3.noarch.rpm". IOW, the architecture string is not easily deducible from 'os.uname()' or 'distutils.util.get_platform()'. No matter how many hacks and heuristics we have to do the "right" thing, especially since there's more to RPM-based Linux distributions than Red Hat. (F'r example, SuSE would call the above to "foo.rpm" and "bar.rpm". Never mind the dubious wisdom of this convention, that's how they do it.) > It seems that for each util.get_platform() there will be a single > value; these can simply be cataloged and a dictionary containing the > mapping stored in the sources (it's not a large dictionary!). I don't want 'get_platform()' to get out of hand -- at some point, I might as well just steal MAL's platform.py, which strikes me as overkill. (At least for now it does...). Anyways, any time you start adding hacks 'n heuristics, you need an escape hatch: that's what the "--arch" option to "bdist_rpm" is for. Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you. From gward@ase.com Wed Apr 26 02:12:18 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 21:12:18 -0400 Subject: [Distutils] patch to make write_manifest respect dry_run In-Reply-To: <20000425040307.E27307@inet.net>; from Harry Henry Gebel on Tue, Apr 25, 2000 at 04:03:07AM -0400 References: <20000425040307.E27307@inet.net> Message-ID: <20000425211218.C465@beelzebub> On 25 April 2000, Harry Henry Gebel said: > Here is a patch that causes sdist.write_manifest() to respect the value of > dry_run. Thanks -- checked in. Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Quick!! Act as if nothing has happened! From gward@ase.com Wed Apr 26 02:18:07 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 21:18:07 -0400 Subject: [Distutils] Just an idea In-Reply-To: <20000425050430.G27307@inet.net>; from Harry Henry Gebel on Tue, Apr 25, 2000 at 05:04:30AM -0400 References: <20000425050430.G27307@inet.net> Message-ID: <20000425211807.D465@beelzebub> On 25 April 2000, Harry Henry Gebel said: > Just an idea for generating both .pyc and .pyo byte code: have a new > command that just generates byte code in an already installed set of > files, (perhaps `setup.py compile_only`), then spawn > > python -o setup.py compile_only > > from within `setup.py install` It has to be something like that, ie. you need to spawn another python interpreter with the opposite debug state of the current one. Obviously, you want to spawn only one interpreter to compile all installed files. (Or files-to-install if you're creating a built distribution that inclues .pyc and/or .pyo files, which is probably what we want to do for RPM -- I think complex/time-consuming post-install scripts are to be avoided. Anyone have experience with this?) The question is, is it worth the complexity and expense of a whole new Distutils command, or should we just spawn a simple "python -c 'compileall(...)'" command, or should be generate a temporary script and run it? I'm leaning towards the generate-a-temporary-script approach. Any thoughts? Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ The world is coming to an end. Please log off. From gward@ase.com Wed Apr 26 02:23:04 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 21:23:04 -0400 Subject: [Distutils] How to build Debian packages (answer) In-Reply-To: ; from Bastian Kleineidam on Tue, Apr 25, 2000 at 11:19:48AM +0200 References: Message-ID: <20000425212304.E465@beelzebub> On 25 April 2000, Bastian Kleineidam said: > heres is the thing I do to build Debian packages: > [reformatted for readability] > [Makefile snippet] > install: ./setup.py install --prefix=/tmp/usr --exec-prefix=/tmp/usr > cp -a /tmp/usr/* $(DESTIDR)/usr # install misc additional files > install -c -m 755 linkchecker $(DESTDIR)/usr/bin ... > > Yes, its a hack, but it works. Umm, I don't get it. How does this generate a Debian package? (Ie. what command spits out a .deb file that Joe Luser can download and install trivially?) (Disclaimer: I am completely ignorant about Debian packages. I tried Debian once, and was utterly stumped by the death-defyingly mysterious "dpkg" interface. Gave up after a few hours and fled back to friendly old Red Hat with RPM's wonderful command-line interface.) Oh, BTW: "If --exec-prefix is not supplied, it defaults to --prefix". (An actual quote from the actual documentation!) Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ A day for firm decisions!!!!! Or is it? From gward@ase.com Wed Apr 26 03:22:58 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 22:22:58 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000425052916.H27307@inet.net>; from Harry Henry Gebel on Tue, Apr 25, 2000 at 05:29:16AM -0400 References: <20000425052916.H27307@inet.net> Message-ID: <20000425222258.F465@beelzebub> On 25 April 2000, Harry Henry Gebel said: > It doesn't look like I will be done with bdist_rpm tonight, here is the > patch for the now install options; they are both intended to be run by RPM > or other packaging systems from within a .spec file (or equivalent) > (although the RPM process may have been launched by another setup.py) Some > things I would like different: I'm not sure I entirely agree with the method this patch. To summarize, for those who didn't take 5 or 10 minutes to read the patch (and 3 months to understand what's going on in distutils.command.install ;-), Harry's patch adds this capability (as I understand it): * when you run "setup.py install --record-install", it installs as usual and writes the list of files installed to INSTALLED_FILES in the current directory * when you run "setup.py install --package-prefix=/tmp --record-install", then it installs to (eg.) /tmp/usr/lib/python1.5/site-packages, and writes the installed filenames -- minus the "/tmp/" prefix -- to INSTALLED_FILES It's the addition of another, somewhat artifical, installation scheme that bothers me about this. I'm also not keen on adding yet another type of "base directory" -- we already have "install_base", "prefix", "exec_prefix", and "home", and now you want to add "root" which is sometimes stuck in ahead of the "install_base". Ugh. Now, the goal is noble: do an installation that looks exactly like what the RPM you're creating will install, except it's not actually in the live Python installation. There's no obvious way to do this with Distutils as it stands, because if you supply --prefix, you have to supply the whole thing -- "/usr/local" or "/tmp/usr" or "/tmp/usr/local" or whatever you want. What you want is a "meta-prefix", which you called the "package prefix" or "root". [...some time passes...] OK, I think I've got it. I've generalized the notion of "configuration variables" to work on the command line, at least the command line of the "install" command. (Config variables will be very important when we start dealing with config files, but they're still useful on the command line. They're even used in the Distutils code: if anyone has looked at the INSTALL_SCHEMES dictionary in install.py, I was *not* smoking drugs, Perl or otherwise, when I wrote that code. They're called configuration variables, and I borrowed the shell/perl syntax because it works. So there.) Anyways, the idea is this: if you want to do a fake install prior to creating an RPM (or what-have-you), you can do this: ./setup.py -n install \ --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix' ...and that does more or less what you might expect. Update your Distutils to the latest CVS -- I'll check this change in shortly -- to see what I mean. Oh, damn! I just remembered that I've already sorta-kinda solved this problem, for the "bdist_dumb" command. There, I did it all in Python code, since there's no need to put shell command in a spec file that will be run later -- so I think the above trick might still be needed for building RPMs. Plus, it's just plain cool, so I think it'll stay unless/until someone thinks of a better way. BTW, the "install" command as I am about to check it in will spew lots of debugging output at you. This is a feature. Please read the output and see if you can grok the latest madness escaping from my fevered imagination. Wouldn't hurt to read the code -- 'finalize_options()' in install.py -- if that's your poison. Brain hurts... off to bed... Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ MTV -- get off the air! -- Dead Kennedys From gward@ase.com Wed Apr 26 03:27:17 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 22:27:17 -0400 Subject: [Distutils] New metadata patch In-Reply-To: <20000425055349.J27307@inet.net>; from Harry Henry Gebel on Tue, Apr 25, 2000 at 05:53:49AM -0400 References: <20000425055349.J27307@inet.net> Message-ID: <20000425222717.G465@beelzebub> On 25 April 2000, Harry Henry Gebel said: > Here is a patch to add a new item to class DistributionMetadata , > long_description. Most of the info for RPMs I am putting in a separate > file, but this seemed appropriate for inclusion in setup.py, it would be > useful, for example, for adding an option to create .lsm files. Thanks, it's in. Even wrote a long_description for the Distutils -- hell, I have to test the occasional change! ;-) Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ I'm a GENIUS! I want to dispute sentence structure with SUSAN SONTAG!! From gward@ase.com Wed Apr 26 03:31:38 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 22:31:38 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000425222258.F465@beelzebub>; from Greg Ward on Tue, Apr 25, 2000 at 10:22:58PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> Message-ID: <20000425223138.I465@beelzebub> On 25 April 2000, I said: > Anyways, the idea is this: if you want to do a fake install prior to > creating an RPM (or what-have-you), you can do this: > > ./setup.py install \ > --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix' > > ...and that does more or less what you might expect. Update your > Distutils to the latest CVS -- I'll check this change in shortly -- to > see what I mean. I forgot to mention that (I think) this will require an extra run of the setup script compared to Harry's scheme: one to do the fake install to /tmp/usr/lib/python1.5, and one to get the list of files (ie. "setup.py install --record-install"). This doesn't bother me a bit, in fact I think it makes more sense than trying to do them both at the same time. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ "WHAT is the airspeed velocity of an unladen swallow?" "What do you mean -- a European or an African swallow?" From gward@ase.com Wed Apr 26 03:42:34 2000 From: gward@ase.com (Greg Ward) Date: Tue, 25 Apr 2000 22:42:34 -0400 Subject: [Distutils] New snapshot Message-ID: <20000425224234.A775@beelzebub> Tonight's patches, crazed and otherwise, are available at http://www.python.org/sigs/distutils-sig/download.html#snapshot enjoy... -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ Time flies like an arrow; fruit flies like a banana. From mwa@gate.net Wed Apr 26 04:30:02 2000 From: mwa@gate.net (Mark W. Alexander) Date: Tue, 25 Apr 2000 23:30:02 -0400 (EDT) Subject: [Distutils] bdist_rpm In-Reply-To: <20000425210056.B465@beelzebub> Message-ID: Since bdist_rpm implies RPM-only, how about using the default architecture from the rpmrc file? Mark Alexander mwa@gate.net On Tue, 25 Apr 2000, Greg Ward wrote: > Date: Tue, 25 Apr 2000 21:00:56 -0400 > From: Greg Ward > To: distutils-sig@python.org > Subject: Re: [Distutils] bdist_rpm > > On 25 April 2000, Fred L. Drake, Jr. said: > > > There should be a "--arch" ("--plat"?) option to "build_rpm" to let > > > people specify the RPM architecture string; it should default to the > > > result of 'util.get_platform()' (eg. "linux2-i586", "sunos5-sun4u"). > > > > Why? > > Because the convention, at least in Red Hat-land, is that RPMs for Linux > on the Intel x86 platform are named like "foo-1.23-1.i386.rpm" or > "bar-3.21-3.noarch.rpm". IOW, the architecture string is not easily > deducible from 'os.uname()' or 'distutils.util.get_platform()'. No > matter how many hacks and heuristics we have to do the "right" thing, > especially since there's more to RPM-based Linux distributions than Red > Hat. (F'r example, SuSE would call the above to "foo.rpm" and > "bar.rpm". Never mind the dubious wisdom of this convention, that's how > they do it.) > > > It seems that for each util.get_platform() there will be a single > > value; these can simply be cataloged and a dictionary containing the > > mapping stored in the sources (it's not a large dictionary!). > > I don't want 'get_platform()' to get out of hand -- at some point, I > might as well just steal MAL's platform.py, which strikes me as > overkill. (At least for now it does...). > > Anyways, any time you start adding hacks 'n heuristics, you need an > escape hatch: that's what the "--arch" option to "bdist_rpm" is for. > > Greg > -- > Greg Ward - Unix nerd gward@python.net > http://starship.python.net/~gward/ > Just because you're paranoid doesn't mean they *aren't* out to get you. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig > From mwa@gate.net Wed Apr 26 04:42:08 2000 From: mwa@gate.net (Mark W. Alexander) Date: Tue, 25 Apr 2000 23:42:08 -0400 (EDT) Subject: [Distutils] Patch for new install options In-Reply-To: <20000425222258.F465@beelzebub> Message-ID: Ok, I'm jumping in late but, what the hell, here goes both feet. If I'm following the --package-prefix theme properly, it's very much in line with RPM's BUILDROOT, and install tree used for 2 very important reasons. First, the package builder need not be root to produce a binary package that installs in directories that only root can write to. Second, it provides for relocatable binary RPM's. I consider the first helpfull, the second mandatory. If I have several machines with different disk partitioning schemes, I want to be able to install the same RPM's on all of them, even if I have to relocate some modules (or even the entire Python tree) and install time. The manual way I've been doing packages (not RPM's, but Solaris pkgs and HP-UX depots), I have the pre- install scripts find the Python install location and automatically relocate to there. (User can override, of course.) Again, I haven't come up to speed yet, but the addition of a "temporary" install tree is far from artificial. Simply being able to test your packaging process without stepping on your production distribution is worth what little effort is required to support it. While I'm still catching up here: Has anyone stepped up to do either Solaris bdist-pkgtool or HP-UX bdist-depot? If not, it looks like a good way for me to start wading in. Mark Alexander mwa@gate.net On Tue, 25 Apr 2000, Greg Ward wrote: > Date: Tue, 25 Apr 2000 22:22:58 -0400 > From: Greg Ward > To: distutils-sig@python.org > Subject: Re: [Distutils] Patch for new install options > > On 25 April 2000, Harry Henry Gebel said: > > It doesn't look like I will be done with bdist_rpm tonight, here is the > > patch for the now install options; they are both intended to be run by RPM > > or other packaging systems from within a .spec file (or equivalent) > > (although the RPM process may have been launched by another setup.py) Some > > things I would like different: > > I'm not sure I entirely agree with the method this patch. To summarize, > for those who didn't take 5 or 10 minutes to read the patch (and 3 > months to understand what's going on in distutils.command.install ;-), > Harry's patch adds this capability (as I understand it): > > * when you run "setup.py install --record-install", it installs > as usual and writes the list of files installed to INSTALLED_FILES > in the current directory > > * when you run "setup.py install --package-prefix=/tmp --record-install", > then it installs to (eg.) /tmp/usr/lib/python1.5/site-packages, > and writes the installed filenames -- minus the "/tmp/" prefix -- > to INSTALLED_FILES > > It's the addition of another, somewhat artifical, installation scheme > that bothers me about this. I'm also not keen on adding yet another > type of "base directory" -- we already have "install_base", "prefix", > "exec_prefix", and "home", and now you want to add "root" which is > sometimes stuck in ahead of the "install_base". Ugh. > > Now, the goal is noble: do an installation that looks exactly like what > the RPM you're creating will install, except it's not actually in the > live Python installation. There's no obvious way to do this with > Distutils as it stands, because if you supply --prefix, you have to > supply the whole thing -- "/usr/local" or "/tmp/usr" or "/tmp/usr/local" > or whatever you want. What you want is a "meta-prefix", which you > called the "package prefix" or "root". > > [...some time passes...] > > OK, I think I've got it. I've generalized the notion of "configuration > variables" to work on the command line, at least the command line of the > "install" command. (Config variables will be very important when we > start dealing with config files, but they're still useful on the command > line. They're even used in the Distutils code: if anyone has looked at > the INSTALL_SCHEMES dictionary in install.py, I was *not* smoking drugs, > Perl or otherwise, when I wrote that code. They're called configuration > variables, and I borrowed the shell/perl syntax because it works. So > there.) > > Anyways, the idea is this: if you want to do a fake install prior to > creating an RPM (or what-have-you), you can do this: > > ./setup.py -n install \ > --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix' > > ...and that does more or less what you might expect. Update your > Distutils to the latest CVS -- I'll check this change in shortly -- to > see what I mean. > > Oh, damn! I just remembered that I've already sorta-kinda solved this > problem, for the "bdist_dumb" command. There, I did it all in Python > code, since there's no need to put shell command in a spec file that > will be run later -- so I think the above trick might still be needed > for building RPMs. Plus, it's just plain cool, so I think it'll stay > unless/until someone thinks of a better way. > > BTW, the "install" command as I am about to check it in will spew lots > of debugging output at you. This is a feature. Please read the output > and see if you can grok the latest madness escaping from my fevered > imagination. Wouldn't hurt to read the code -- 'finalize_options()' in > install.py -- if that's your poison. > > Brain hurts... off to bed... > > Greg > -- > Greg Ward - just another /P(erl|ython)/ hacker gward@python.net > http://starship.python.net/~gward/ > MTV -- get off the air! > -- Dead Kennedys > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig > From hgebel@inet.net Wed Apr 26 05:01:56 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Wed, 26 Apr 2000 00:01:56 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: ; from mwa@gate.net on Tue, Apr 25, 2000 at 11:42:08PM -0400 References: <20000425222258.F465@beelzebub> Message-ID: <20000426000156.C31051@inet.net> On Tue, Apr 25, 2000 at 11:42:08PM -0400, Mark W. Alexander wrote: > If I'm following the --package-prefix theme properly, it's > very much in line with RPM's BUILDROOT, and install tree > used for 2 very important reasons. First, the package > builder need not be root to produce a binary package > that installs in directories that only root can write > to. Second, it provides for relocatable binary RPM's. Yes, I wrote added --package-prefix specifically to be used in the following command in an RPM .spec file. python setup.py --package-prefix=$RPM_BUILD_ROOT --record-install I haven't looked at the latest CVS yet, just got up. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From hgebel@inet.net Wed Apr 26 05:06:26 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Wed, 26 Apr 2000 00:06:26 -0400 Subject: [Distutils] Just an idea In-Reply-To: <20000425211807.D465@beelzebub>; from gward@ase.com on Tue, Apr 25, 2000 at 09:18:07PM -0400 References: <20000425050430.G27307@inet.net> <20000425211807.D465@beelzebub> Message-ID: <20000426000626.D31051@inet.net> On Tue, Apr 25, 2000 at 09:18:07PM -0400, Greg Ward wrote: > On 25 April 2000, Harry Henry Gebel said: > > Just an idea for generating both .pyc and .pyo byte code: have a new > > command that just generates byte code in an already installed set of > > files, (perhaps `setup.py compile_only`), then spawn > > > > python -o setup.py compile_only > > > > from within `setup.py install` > > The question is, is it worth the complexity and expense of a whole new > Distutils command, or should we just spawn a simple "python -c > 'compileall(...)'" command, or should be generate a temporary script and > run it? > > I'm leaning towards the generate-a-temporary-script approach. Any thoughts? Yes, a temporary script is better, it was in the working on bdist_rpm (which has a child process of setup.py (rpm) running it's own copy of setup.py) that put in me in the frame of mind for my idea. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From hgebel@inet.net Wed Apr 26 10:02:44 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Wed, 26 Apr 2000 05:02:44 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000425222258.F465@beelzebub>; from gward@ase.com on Tue, Apr 25, 2000 at 10:22:58PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> Message-ID: <20000426050244.E31051@inet.net> On Tue, Apr 25, 2000 at 10:22:58PM -0400, Greg Ward wrote: > On 25 April 2000, Harry Henry Gebel said: > > It doesn't look like I will be done with bdist_rpm tonight, here is the > > patch for the now install options; they are both intended to be run by RPM > > or other packaging systems from within a .spec file (or equivalent) > > (although the RPM process may have been launched by another setup.py) Some > > * when you run "setup.py install --record-install", it installs > as usual and writes the list of files installed to INSTALLED_FILES > in the current directory > > * when you run "setup.py install --package-prefix=/tmp --record-install", > then it installs to (eg.) /tmp/usr/lib/python1.5/site-packages, > and writes the installed filenames -- minus the "/tmp/" prefix -- > to INSTALLED_FILES > > It's the addition of another, somewhat artifical, installation scheme > that bothers me about this. I'm also not keen on adding yet another > type of "base directory" -- we already have "install_base", "prefix", > "exec_prefix", and "home", and now you want to add "root" which is > sometimes stuck in ahead of the "install_base". Ugh. > > Now, the goal is noble: do an installation that looks exactly like what > the RPM you're creating will install, except it's not actually in the > live Python installation. There's no obvious way to do this with > Distutils as it stands, because if you supply --prefix, you have to > supply the whole thing -- "/usr/local" or "/tmp/usr" or "/tmp/usr/local" > or whatever you want. What you want is a "meta-prefix", which you > called the "package prefix" or "root". It doesn't seem like an artificial scheme to me, it is a standard method used in many RPMs, in fact almost all RPMs install into a temporary tree in order to avoid the need for root access and to preserve a system's existing installed programs, the '--package-prefix' option provides a simple and direct method of doing this. And if you can fit all of the options on one screen you don't have too many :) > ./setup.py -n install \ > --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix' While this works perfectly fine, my problems with it is that it is not pretty and it presupposes that someone reading the spec file has some knowledge of the internal operations of Distutils. It is even uglier as it will appear in an actual spec file (I'm not sure why the above is a dry run, so I left the -n off of this example): ./setup.py install --prefix=$RPM_BUILD_ROOT'$sys_prefix' \ --exec-prefix=$RPM_BUILD_ROOT'$sys_exec_prefix' Compare this with: ./setup.py install --package-prefix=$RPM_BUILD_ROOT Of course, if we assume that the generated spec file will never be seen by human eyes none of this matters, but spec files are looked at by many people, such as people who are making RPMs of patched distributions, people who are trying to learn how to use RPM and people who are simply curious about what is going when they build RPMs. I think in is important to present them with a simple and clear spec file. It is true that many (most) install scripts (and makefile install targets) require just these sorts of shenanigans (and worse) to use in RPM; but as the saying goes, if all those other guys jumped off the St. Georges Bridge ... Also, with this code if you ever changed the meaning of sys_prefix or sys_exec_prefix (or replaced them with something else) people with old source RPMs would no longer be able to build them on machines running a version of Distutils with the new conventions. While the meaning of these attributes may be unlikely to change, I think it is a bad idea in principle to display internals in this manner, and thereby lock yourself into certain ways of doing things. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware "Why do you look for the living among the dead? He is not here, but has risen." Luke 24:5 (NRSV) From hgebel@inet.net Wed Apr 26 10:38:31 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Wed, 26 Apr 2000 05:38:31 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000425223138.I465@beelzebub>; from gward@ase.com on Tue, Apr 25, 2000 at 10:31:38PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> <20000425223138.I465@beelzebub> Message-ID: <20000426053831.F31051@inet.net> On Tue, Apr 25, 2000 at 10:31:38PM -0400, Greg Ward wrote: > I forgot to mention that (I think) this will require an extra run of the > setup script compared to Harry's scheme: one to do the fake install to > /tmp/usr/lib/python1.5, and one to get the list of files (ie. "setup.py > install --record-install"). This doesn't bother me a bit, in fact I > think it makes more sense than trying to do them both at the same time. I must be in a contentious mood tonight, but here goes ;) If you make the file list using a separate step, you are basically throwing away all the data that the install left in get_outputs(), data that is just sitting there begging for somebody to use it. If the setup script has be run again (and in RPM spec files the file lists are usually generate immediately after the install script is run) all it is doing is regenerating data that was there for the taking a few moments ago. Of course you could also do something like this (copied verbatim from Mandrake's python spec file): rm -f modules-list.full for n in $RPM_BUILD_ROOT/usr/lib/python1.5/*; do [ -d $n ] || echo $n done >> modules-list.full for mod in $RPM_BUILD_ROOT/usr/lib/python1.5/lib-dynload/* ; do [ `basename $mod` = _tkinter.so ] || echo $mod done >> modules-list.full sed -e "s|$RPM_BUILD_ROOT||g" < modules-list.full > modules-list #get files list for python-tools DIR1=$RPM_BUILD_ROOT/usr/lib/python1.5/site-packages/pynche DIR2=$RPM_BUILD_ROOT/usr/lib/python1.5/site-packages/idle DIR3=$RPM_BUILD_ROOT/usr/lib/python1.5/site-packages/modulator find $DIR1 -type f | sed -e "s#^$RPM_BUILD_ROOT##g" > python-tools.files find $DIR2 -type f | sed -e "s#^$RPM_BUILD_ROOT##g" >> python-tools.files find $DIR3 -type f | sed -e "s#^$RPM_BUILD_ROOT##g" >> python-tools.files Sorry about that not-very-applicable example, for most python modules this would be as simple as: find $RPM_BUILD_ROOT/usr/lib/python1.5/site-packages/pyncurses -type f > files But still, just adding --record-install is even easier, and is an option I have wished for on every spec file I have ever written. I once made my own custom RPM based distribution, and got to become very tired of the things existing install scripts made me do to right a spec file (and don't even get me started on the actual install parts of many spec file install scripts). This is why I use Mandrake now instead of my own, I let somebody else worry about that stuff now. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne From calvin@cs.uni-sb.de Wed Apr 26 12:40:41 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Wed, 26 Apr 2000 13:40:41 +0200 (CEST) Subject: [Distutils] How to build Debian packages (answer) In-Reply-To: <20000425212304.E465@beelzebub> Message-ID: >Umm, I don't get it. How does this generate a Debian package? >(Ie. what command spits out a .deb file that Joe Luser can download and >install trivially?) That would be "debian/rules binary". The rules script calls $(MAKE) install DESTDIR=`pwd`/debian/tmp and expects that this call installs everything in debian/tmp. Output of the rules script is a .deb package in the parent directory. You install .deb packages with "dpkg --install blubb_0.1.0_i386.deb". You deinstall packages with "dpkg --remove blubb". You purge packages with "dpkg --purge blubb". Purging additionally removes any config files of the package while --remove leaves them so you do not have to reconfigure if you install the package again. Bastian -- Bastian Kleineidam -- Isch hab noch viel krasseres System... .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^ From fdrake@acm.org Wed Apr 26 15:20:46 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 26 Apr 2000 10:20:46 -0400 (EDT) Subject: [Distutils] bdist_rpm In-Reply-To: References: <20000425210056.B465@beelzebub> Message-ID: <14598.64318.406634.655865@seahag.cnri.reston.va.us> Mark W. Alexander writes: > Since bdist_rpm implies RPM-only, how about using the > default architecture from the rpmrc file? Excellent! The only thing to think about is the arch/noarch distinction, which we have to be aware of anyway. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Wed Apr 26 20:34:17 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 26 Apr 2000 15:34:17 -0400 (EDT) Subject: [Distutils] PATCH: Expanded tarball abilites In-Reply-To: <20000425205132.A465@beelzebub> References: <20000424013348.H8616@inet.net> <20000424214136.A633@beelzebub> <20000424235853.C27307@inet.net> <20000425205132.A465@beelzebub> Message-ID: <14599.17593.184163.37961@seahag.cnri.reston.va.us> Greg Ward writes: > Okee-dokey. If anyone's interested, it would still be mildly > interesting and useful to detect GNU tar and use the -z option, and to > detect GNU tar >= 1.13 and use the "base directory" option. Not > essential, but it's one of those things that makes the Distutils look Sounds like extraneous cruft to me. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From hgebel@inet.net Wed Apr 26 21:30:51 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Wed, 26 Apr 2000 16:30:51 -0400 Subject: [Distutils] Patch for bdist_rpm Message-ID: <20000426163051.C32467@inet.net> --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Okay, three attachments to this message 1) patch against CVS to add bdist_rpm 2) bdist_rpm.py 3) a sample package_data file for Distutils that can be used to build a Distutils RPM (it will build an RPM without the file) I have to leave for a meeting, but when I get back I will post instructions. The patch uses --package-prefix and --record-install, but if you don't want to use them just change bdist_rpm.py lines 191-192 to the command you want to use to install. No options at this time, but I have several I am adding tonight. There are several caveats to the command as in stands now, they will no longer apply after I add the options. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.net --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bdist_rpm.patch" ? build ? MANIFEST ? rpm.patch ? dry_run.patch ? redhat ? package_data ? INSTALLED_FILES ? install_options.patch ? long_description.patch ? exeception_error.patch ? bdist_rpm.patch ? Distutils-0.8.2.tar.gz ? distutils/command/bdist_rpm.py Index: MANIFEST.in =================================================================== RCS file: /projects/cvsroot/distutils/MANIFEST.in,v retrieving revision 1.4 diff -u -r1.4 MANIFEST.in --- MANIFEST.in 2000/04/21 04:38:11 1.4 +++ MANIFEST.in 2000/04/26 20:26:56 @@ -9,7 +9,9 @@ # include *.txt +include package_data include MANIFEST.in +include redhat/*.spec recursive-include examples *.txt *.py prune examples/sample?/build recursive-include doc *.sty *.tex Index: distutils/command/__init__.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/__init__.py,v retrieving revision 1.8 diff -u -r1.8 __init__.py --- __init__.py 2000/03/31 03:14:51 1.8 +++ __init__.py 2000/04/26 20:26:58 @@ -15,4 +15,5 @@ 'sdist', 'bdist', 'bdist_dumb', + 'bdist_rpm', ] Index: distutils/command/bdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/bdist.py,v retrieving revision 1.5 diff -u -r1.5 bdist.py --- bdist.py 2000/04/25 01:38:19 1.5 +++ bdist.py 2000/04/26 20:26:58 @@ -31,8 +31,12 @@ 'bztar': 'bdist_dumb', 'ztar': 'bdist_dumb', 'tar': 'bdist_dumb', - 'zip': 'bdist_dumb', } + 'zip': 'bdist_dumb', + 'rpm': 'bdist_rpm', + } + # The following commands do not take a format option from bdist + no_format_option = ( 'bdist_rpm', ) def initialize_options (self): self.format = None @@ -63,8 +67,9 @@ raise DistutilsOptionError, \ "invalid archive format '%s'" % self.format - sub_cmd = self.find_peer (cmd_name) - sub_cmd.set_option ('format', self.format) + if cmd_name not in self.no_format_option: + sub_cmd = self.find_peer (cmd_name) + sub_cmd.set_option ('format', self.format) self.run_peer (cmd_name) # run() Index: distutils/command/install.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/install.py,v retrieving revision 1.22 diff -u -r1.22 install.py --- install.py 2000/04/26 02:38:01 1.22 +++ install.py 2000/04/26 20:27:01 @@ -12,6 +12,7 @@ from distutils import sysconfig from distutils.util import write_file, native_path, subst_vars from distutils.errors import DistutilsOptionError +from glob import glob INSTALL_SCHEMES = { 'unix_prefix': { @@ -20,6 +21,12 @@ 'scripts': '$base/bin', 'data' : '$base/share', }, + 'unix_package_prefix': { + 'purelib': '$root/$base/lib/python$py_version_short/site-packages', + 'platlib': '$root/$platbase/lib/python$py_version_short/site-packages', + 'scripts': '$root/$base/bin', + 'data' : '$root/$base/share', + }, 'unix_home': { 'purelib': '$base/lib/python', 'platlib': '$base/lib/python', @@ -54,6 +61,11 @@ ('home=', None, "(Unix only) home directory to install under"), + # treats package prefix like root directory + ('package-prefix=', None, + "(For use by packaging systems) prefix is treated like " \ + "root directory"), + # Or, just set the base director(y|ies) ('install-base=', None, "base installation directory (instead of --prefix or --home)"), @@ -80,6 +92,9 @@ #('install-man=', None, "directory for Unix man pages"), #('install-html=', None, "directory for HTML documentation"), #('install-info=', None, "directory for GNU info files"), + + ('record-install', None, + "make a record of installation") ] @@ -114,6 +129,7 @@ self.install_lib = None # set to either purelib or platlib self.install_scripts = None self.install_data = None + self.package_prefix = None # will be prepended to any other dirs # These two are for putting non-packagized distributions into their # own directory and creating a .pth file if it makes sense. @@ -138,6 +154,7 @@ #self.install_html = None #self.install_info = None + self.record_install = None def finalize_options (self): @@ -167,6 +184,9 @@ raise DistutilsOptionError, \ ("must supply either home or prefix/exec-prefix -- " + "not both") + if self.home and self.package_prefix: + raise DistutilsOptionError, \ + ("cannot supply both home and package prefix") else: if self.exec_prefix: self.warn ("exec-prefix option ignored on this platform") @@ -174,6 +194,9 @@ if self.home: self.warn ("home option ignored on this platform") self.home = None + if self.package_prefix: # for now + self.warn ("package-prefix option ignored on this platform") + self.package_prefix = None # Now the interesting logic -- so interesting that we farm it out # to other methods. The goal of these methods is to set the final @@ -213,6 +236,7 @@ # everything else. self.config_vars['base'] = self.install_base self.config_vars['platbase'] = self.install_platbase + self.config_vars['root'] = self.package_prefix print "config vars:" pprint (self.config_vars) @@ -296,7 +320,10 @@ self.install_base = self.prefix self.install_platbase = self.exec_prefix - self.select_scheme ("unix_prefix") + if self.package_prefix: + self.select_scheme("unix_package_prefix") + else: + self.select_scheme ("unix_prefix") # finalize_unix () @@ -404,6 +431,22 @@ "Python's module search path (sys.path) -- " + "you'll have to change the search path yourself") % self.install_lib) + + # write list of installed files, if requested. + if self.record_install: + outputs = self.get_outputs() + for counter in xrange (len (outputs)): # include ".pyc" and ".pyo" + if outputs[counter][-3:] == ".py": + byte_code = glob(outputs[counter] + '[co]') + outputs.extend(byte_code) + outputs.sort() # just makes it look nicer + if self.package_prefix: # strip any package prefix + prefix_len = len(self.package_prefix) + 1 + for counter in xrange (len (outputs)): + outputs[counter] = outputs[counter][prefix_len:] + self.execute(write_file, + ("INSTALLED_FILES", outputs), + "Writing list of installed files") # run () --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=package_data release = '1' group = 'Development/Libraries' vendor = 'Distutils-SIG' packager = 'Harry Henry Gebel ' doc = ['CHANGES.txt', 'README.txt', 'USAGE.txt', 'doc/', 'examples/', ] changelog = '''\ * Wed Apr 26 2000 Harry Henry Gebel 0.8.2-1 - First test of bdist_rpm''' --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bdist_rpm.py" """distutils.command.bdist_rpm Implements the Distutils 'bdist_rpm' command (create RPM source and binary distributions.""" # created 2000/04/25, Greg Ward __revision__ = "$Id: bdist_dumb.py,v 1.3 2000/04/22 02:51:25 gward Exp $" import os.path from distutils.core import Command from distutils.util import mkpath, write_file from distutils.errors import * from string import join class bdist_rpm (Command): description = "create an RPM distribution" user_options = [] def initialize_options (self): pass # initialize_options() def finalize_options (self): if os.name != 'posix': raise DistutilsPlatformError, \ ("don't know how to create RPM " "distributions on platform %s") % os.name # finalize_options() def run (self): self._getPackageData() # get packaging info # place spec file in ./redhat directory self.execute(mkpath, ('./redhat',), "Created ./redhat directory") spec_path = './redhat/%s.spec' % self.name self.execute(write_file, (spec_path, self._makeSpecFile()), 'Writing .spec file') # make a .gz distribution sdist = self.find_peer ('sdist') sdist.set_option ('formats', ['gztar']) self.run_peer('sdist') # build package self.announce('Building RPMs') self.spawn(['rpm', '-ta', '--clean', self.distribution.get_fullname() + '.tar.gz']) def _getPackageData(self): ''' Get data needed to generate spec file, first from the DistributionMetadata class, then from the package_data file, which is Python code read with execfile() ''' # read in package data, if any if os.path.exists('package_data'): try: exec(open('package_data')) except: raise DistutilsOptionError, 'Error in package data file' # set instance variables, supplying default value if not provided in # package data file vars = locals().keys() if 'name' in vars: self.name = name else: self.name = self.distribution.get_name() if 'version' in vars: self.version = version else: self.version = self.distribution.get_version() if 'summary' in vars: self.summary = summary else: self.summary = self.distribution.get_description() if 'decription' in vars: self.description = description else: self.description = self.distribution.get_long_description() if 'summaries' in vars: self.summaries = summaries else: self.summaries = {} if 'descriptions' in vars: self.descriptions = descriptions else: self.descriptions = {} if 'copyright' in vars: self.copyright = copyright else: self.copyright = self.distribution.get_licence() if 'release' in vars: self.release = release else: self.release = '1' if 'group' in vars: self.group = group else: self.group = 'Applications' if 'vendor' in vars: self.vendor = vendor else: self.vendor = None if 'packager' in vars: self.packager = packager else: self.packager = None if 'url' in vars: self.url = url else: self.url = self.distribution.get_url() if 'doc' in vars: self.doc = join(doc, ' ') else: self.doc = None if 'changelog' in vars: self.changelog = changelog else: self.changelog = None def _makeSpecFile(self): ''' Generate an RPM spec file ''' spec_file = [ '%define name ' + self.name, '%define version ' + self.version, '%define release ' + self.release, '', 'Summary: ' + self.summary, ] # put locale summaries into spec file for locale in self.summaries.keys(): spec_file.append('Summary(%s): %s' % (locale, self.summaries[locale])) spec_file.extend([ 'Name: %{name}', 'Version: %{version}', 'Release: %{release}', 'Source0: %{name}-%{version}.tar.gz', 'Copyright: ' + self.copyright, 'Group: ' + self.group, 'BuildRoot: %{_tmppath}/%{name}-buildroot', 'Prefix: %{_prefix}', ]) if not self.distribution.has_ext_modules(): spec_file.append('BuildArchitectures: noarch') if self.vendor: spec_file.append('Vendor: ' + self.vendor) if self.packager: spec_file.append('Packager: ' + self.packager) if self.url: spec_file.append('Url: ' + self.url) spec_file.extend([ '', '%description', self.description]) # put locale descriptions into spec file for locale in self.descriptions.keys(): spec_file.extend([ '', '%description -l ' + locale, self.descriptions[locale], ]) spec_file.extend([ '', '%prep', '%setup', '', '%build', 'python setup.py build', '', '%install', 'python setup.py install --package-prefix $RPM_BUILD_ROOT ' '--record-install', '', '%clean', 'rm -rf $RPM_BUILD_ROOT', 'rm -f INSTALLED_FILES', '', '%files -f INSTALLED_FILES', '%defattr(-,root,root)', ]) if self.doc: spec_file.append('%doc ' + self.doc) if self.changelog: spec_file.extend([ '', '%changelog', self.changelog ]) return spec_file # run() --AhhlLboLdkugWU4S-- From gward@ase.com Thu Apr 27 02:11:43 2000 From: gward@ase.com (Greg Ward) Date: Wed, 26 Apr 2000 21:11:43 -0400 Subject: [Distutils] bdist_rpm In-Reply-To: ; from Mark W. Alexander on Tue, Apr 25, 2000 at 11:30:02PM -0400 References: <20000425210056.B465@beelzebub> Message-ID: <20000426211143.A747@beelzebub> On 25 April 2000, Mark W. Alexander said: > Since bdist_rpm implies RPM-only, how about using the > default architecture from the rpmrc file? 'Cause I totally forgot about the rpmrc file, of course! Hmmm... I don't see anything in my /etc/rpmrc which would set the architecture string, though. Does RPM just figure it out for the current platform? Also, is there any sort of standard emerging for better platform strings in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you want to live in a world where Solaris, Linux, and *BSD all use RPMs. (Yes yes, I know they *don't*, but it's a nice idea...) Greg PS. as I mentioned earlier, the "noarch" distinction is easily handled: "if not self.distribution.has_ext_modules()" somewhere in the bdist_rpm command. -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ We have always been at war with Oceania. From gward@ase.com Thu Apr 27 02:27:14 2000 From: gward@ase.com (Greg Ward) Date: Wed, 26 Apr 2000 21:27:14 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000426050244.E31051@inet.net>; from Harry Henry Gebel on Wed, Apr 26, 2000 at 05:02:44AM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> <20000426050244.E31051@inet.net> Message-ID: <20000426212714.B747@beelzebub> [my proposed solution to the "fake install" problem] > ./setup.py -n install \ > --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix' [Harry begs to differ] > While this works perfectly fine, my problems with it is that it is not > pretty and it presupposes that someone reading the spec file has some > knowledge of the internal operations of Distutils. It is even uglier as > it will appear in an actual spec file (I'm not sure why the above is a dry > run, so I left the -n off of this example): > > ./setup.py install --prefix=$RPM_BUILD_ROOT'$sys_prefix' \ > --exec-prefix=$RPM_BUILD_ROOT'$sys_exec_prefix' > > Compare this with: > > ./setup.py install --package-prefix=$RPM_BUILD_ROOT Hmmm, you have a point. When generating built distributions, you really do want to sneak a new root directory into the installation paths. So how about this minor spelling change: ./setup.py install --root=$RPM_BUILD_ROOT and, instead of having a new artifical "unix_package_prefix" scheme (BTW, *that's* what I was calling artificial, not the idea of a --root or --package-prefix option), a little bit of code somewhere in 'finalize_options()' would do this: if self.root is not None: for attr in ('install_lib', 'install_scripts', ...): setattr (self, attr, os.path.join (self.root, getattr (self, attr))) This would have to be pretty late in the game: after expanding all config vars, after setting 'install_lib', and after 'handle_extra_path()'. So yeah, we would have yet another kind of "base directory", which still bothers me a little bit. However, it would only be needed for generating built distributions, and use of it would usually be buried inside one of the bdist_* commands... so I guess I can live with it. I'm going to have to think about how to fix/simplify the 'bdist_dumb' command now -- it does a lot of this stuff on its own, and it probably should be done by the "install" command. One useful side-effect is that this will fix the bug whereby .pth files don't get included in built distributions, since the mock install is done by the "install" command, as it should be. Yeah, OK, I'm starting to like this. Grudgingly. ;-) Greg PS. using "--prefix='/tmp$sys_prefix'" won't require knowledge of Distutils internals, since the configuration variables will be a documented part of the interface. I admit that it's still a tricky and specialized part of the interface though, and it would be best to restrict config vars to the config file if at all possible. It just seems bogus to *disallow* them from the command line when they might be useful, hence last night's hack. Err, patch. -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ UFO's are for real: the Air Force doesn't exist. From gward@ase.com Thu Apr 27 03:00:20 2000 From: gward@ase.com (Greg Ward) Date: Wed, 26 Apr 2000 22:00:20 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000426212714.B747@beelzebub>; from Greg Ward on Wed, Apr 26, 2000 at 09:27:14PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> <20000426050244.E31051@inet.net> <20000426212714.B747@beelzebub> Message-ID: <20000426220020.C747@beelzebub> On 26 April 2000, I said: > Hmmm, you have a point. When generating built distributions, you really > do want to sneak a new root directory into the installation paths. So > how about this minor spelling change: > > ./setup.py install --root=$RPM_BUILD_ROOT OK, I've added this option to the install command. Works for me, but it will blow up on Windows and Mac OS because I'm not sure of the right way to forcibly set a new root directory on a path that might already be absolute. Probably just because my brain is running at a low ebb tonight. Anyways, take a look in distutils/util.py at 'change_root()' in the latest CVS if you can help me. Still haven't added Harry's --record-install option, or something like it. Tomorrow... Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ If it can't be expressed in figures, it is not science--it is opinion. From gward@ase.com Thu Apr 27 03:14:47 2000 From: gward@ase.com (Greg Ward) Date: Wed, 26 Apr 2000 22:14:47 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: ; from Mark W. Alexander on Tue, Apr 25, 2000 at 11:42:08PM -0400 References: <20000425222258.F465@beelzebub> Message-ID: <20000426221447.B746@beelzebub> On 25 April 2000, Mark W. Alexander said: > If I'm following the --package-prefix theme properly, it's > very much in line with RPM's BUILDROOT, and install tree > used for 2 very important reasons. First, the package > builder need not be root to produce a binary package > that installs in directories that only root can write > to. Second, it provides for relocatable binary RPM's. Yeah, I think Harry and you won, although I implemented it differently from Harry's --package-prefix patch. Try "install --root=/tmp" and see how it works for you. (It works for me)! > While I'm still catching up here: Has anyone stepped up > to do either Solaris bdist-pkgtool or HP-UX bdist-depot? > If not, it looks like a good way for me to start wading > in. No, please wade right in. You might want to wait a few days until I have fixed "bdist_dumb" to use the latest changes to "install", and until Harry and I agree on what "bdist_rpm" should look like. Or go ahead and start playing around, but be prepared to hack your "bdist_xxx" commands up when I change my mind about how things should look. Yeah, on second thought, start playing around... rearranging Python code is cheap. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ And I wonder ... will Elvis take the place of Jesus in a thousand years? -- Dead Kennedys From hgebel@inet.net Thu Apr 27 05:16:15 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu, 27 Apr 2000 00:16:15 -0400 Subject: [Distutils] bdist_rpm In-Reply-To: <20000426211143.A747@beelzebub>; from gward@ase.com on Wed, Apr 26, 2000 at 09:11:43PM -0400 References: <20000425210056.B465@beelzebub> <20000426211143.A747@beelzebub> Message-ID: <20000427001615.E32467@inet.net> > Also, is there any sort of standard emerging for better platform strings > in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you > want to live in a world where Solaris, Linux, and *BSD all use RPMs. > (Yes yes, I know they *don't*, but it's a nice idea...) I did a quick skim through rpmfind.net, and all of the Solaris RPMs I saw had solaris within the package name, but I think this was a convention one packager and not a standard of any kind. --=20 Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne From hgebel@inet.net Thu Apr 27 05:25:25 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu, 27 Apr 2000 00:25:25 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000426212714.B747@beelzebub>; from gward@ase.com on Wed, Apr 26, 2000 at 09:27:14PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> <20000426050244.E31051@inet.net> <20000426212714.B747@beelzebub> Message-ID: <20000427002525.F32467@inet.net> On Wed, Apr 26, 2000 at 09:27:14PM -0400, Greg Ward wrote: > > ./setup.py install --prefix=$RPM_BUILD_ROOT'$sys_prefix' \ > > --exec-prefix=$RPM_BUILD_ROOT'$sys_exec_prefix' > > > > Compare this with: > > > > ./setup.py install --package-prefix=$RPM_BUILD_ROOT > > Hmmm, you have a point. When generating built distributions, you really > do want to sneak a new root directory into the installation paths. So > how about this minor spelling change: > > ./setup.py install --root=$RPM_BUILD_ROOT That's better, I never was good at thinking up names. > PS. using "--prefix='/tmp$sys_prefix'" won't require knowledge of > Distutils internals, since the configuration variables will be a > documented part of the interface. I admit that it's still a tricky and > specialized part of the interface though, and it would be best to > restrict config vars to the config file if at all possible. It just > seems bogus to *disallow* them from the command line when they might be > useful, hence last night's hack. Err, patch. I agree, disallowing them is wrong too, I just didn't think in was a good idea in that location where people would, in a sense, be using them without realizing it. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne From hgebel@inet.net Thu Apr 27 05:39:35 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu, 27 Apr 2000 00:39:35 -0400 Subject: [Distutils] Patch for new install options In-Reply-To: <20000426220020.C747@beelzebub>; from gward@ase.com on Wed, Apr 26, 2000 at 10:00:20PM -0400 References: <20000425052916.H27307@inet.net> <20000425222258.F465@beelzebub> <20000426050244.E31051@inet.net> <20000426212714.B747@beelzebub> <20000426220020.C747@beelzebub> Message-ID: <20000427003935.G32467@inet.net> On Wed, Apr 26, 2000 at 10:00:20PM -0400, Greg Ward wrote: > On 26 April 2000, I said: > > ./setup.py install --root=$RPM_BUILD_ROOT > > OK, I've added this option to the install command. Works for me, but it > will blow up on Windows and Mac OS because I'm not sure of the right way > to forcibly set a new root directory on a path that might already be > absolute. Probably just because my brain is running at a low ebb > tonight. Anyways, take a look in distutils/util.py at 'change_root()' > in the latest CVS if you can help me. This is basically why --package-prefix didn't support Mac and Windows, because don't know much about Windows path conventions, or anything about Mac, so I thought it would be better to let someone who was familiar with those platforms fill it in. -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne From hgebel@inet.net Thu Apr 27 06:43:05 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu, 27 Apr 2000 01:43:05 -0400 Subject: [Distutils] Instructions for bdist_rpm Message-ID: <20000427014305.H32467@inet.net> Okay, here are the directions for bdist_rpm To run: ./setup.py bdist --format=rpm or ./setep.py bdist_rpm Will build an RPM using DistributionMetaData to get package information. Additional information can be put in the file 'package_data'. 'package_data' contains python code setting the following variables (variables marked with * are by default set from DistributionMetaData and do not be need assigned in package_data unless you need to override the values in .setup.py): *name - name of package *version - package version *summary - short summary of package *description - long summary of package summaries - a dictionary, keys are locales and values are summaries for that locale. descriptions - a dictionary, keys are locales and values are descriptions for that locale. *copyright - the license used by rpm release - the release of the rpm (for example '1mdk') group - the group the package belongs to vendor - the package's vendor packager - the package's packager *url - the package's URL doc - a list of string containing names of files and directories to put in the system's documentation directory. changelog - a string containing a properly formated changelog (I haven't tried it, but I'm pretty sure RPM will exit with an error if it is fed an improperly format changelog) Unless otherwise noted these must all be strings. There is no type checking yet, I would like people's opinion: should they be cast to strings or should an exception be raised if they are not strings? Or maybe some combination; for example releases are (especially on RedHat) often numerals, so it might be natural to allow a numeric value and cast it to a string, but a value like '8' would probably never make sense for something like 'copyright', so an exception would be raised. 'package_data's local namespace includes the variable 'package_type' which is set to 'rpm', this variable will hopefully allow 'package_data' to be used for all bdist_* commands . bdist_rpm works by making a spec file and saving it into the 'redhat/' directory (making the directory if necessary), it then produces a gzipped source tarball and runs `rpm -ta --clean` on the tarball. bdist_rpm leaves the spec file and tarball around since they would probably be wanted anyway. Here are the caveats I mentioned. If you have not configured rpm to allow you to build RPMs without being root you will have a directory and three files (the redhat/ directory and spec file, the MANIFEST file, and the tarball) saying around owned by root. The other caution is that the spec file must be included in MANIFEST.in, otherwise it will not be included in the tarball and therefore the tarball will not be buildable with rpm. The first will be solved with an option I am adding tonight which will just generate the spec file and tarball, the user can then su and run 'rpm -ta' on the tarball. The MANIFEST problem I don't know what is the best way to solve, should the spec file be automatically added like setup.py, should bdist_rpm add it to the MANIFEST itself, or should it remain the user's responsibility? If it is automatically included should package_data also be automatically included?, if a user alters the package in some way they will want to change the 'release' variable and regenerate the spec file, this will be easier if they have 'package_data' What is everybody's input on the above? -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne From hgebel@inet.net Thu Apr 27 10:50:48 2000 From: hgebel@inet.net (Harry Henry Gebel) Date: Thu, 27 Apr 2000 05:50:48 -0400 Subject: [Distutils] Update bdist_rpm patch Message-ID: <20000427055048.J32467@inet.net> --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Okay, here is a new version of the bdist_rpm patch, it adds the following options: --spec-only - This option just generates a spec file and then stops --tar-only - This option just generates a tarball and stops. The command `rpm -ta program_name.tar.gz` will then build an RPM --no-remove - bdist_rpm now by default will remove MANIFEST, redhat/, and program_name.tar.gz when run as root. This option will disable this behavior --arch - This option will build the RPM for the specified architecture. One important consideration for --arch : Unless ./setup.py can be made to recognize the rpm's CFLAGS it will generate the same object code no matter what architecture you specify. In this case --arch will only effect what rpm THINKS the package is. I looked through the ccompiler and unixccompiler modules and didn't find any way to pass any CFLAGS in either through the command line or through an environment variable, am I missing it or has this feature not been added yet? -- Harry Henry Gebel, Senior Developer, Landon House SBS West Dover Hundred, Delaware PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.net --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bdist_rpm.patch" ? build ? redhat ? rpm.patch ? dry_run.patch ? MANIFEST ? package_data ? install_options.patch ? long_description.patch ? exeception_error.patch ? bdist_rpm.patch ? Distutils-0.8.2.tar.gz ? distutils/command/bdist_rpm.py Index: MANIFEST.in =================================================================== RCS file: /projects/cvsroot/distutils/MANIFEST.in,v retrieving revision 1.4 diff -u -r1.4 MANIFEST.in --- MANIFEST.in 2000/04/21 04:38:11 1.4 +++ MANIFEST.in 2000/04/27 09:29:32 @@ -9,7 +9,9 @@ # include *.txt +include package_data include MANIFEST.in +include redhat/*.spec recursive-include examples *.txt *.py prune examples/sample?/build recursive-include doc *.sty *.tex Index: distutils/command/__init__.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/__init__.py,v retrieving revision 1.8 diff -u -r1.8 __init__.py --- __init__.py 2000/03/31 03:14:51 1.8 +++ __init__.py 2000/04/27 09:29:35 @@ -15,4 +15,5 @@ 'sdist', 'bdist', 'bdist_dumb', + 'bdist_rpm', ] Index: distutils/command/bdist.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/bdist.py,v retrieving revision 1.5 diff -u -r1.5 bdist.py --- bdist.py 2000/04/25 01:38:19 1.5 +++ bdist.py 2000/04/27 09:29:35 @@ -31,8 +31,12 @@ 'bztar': 'bdist_dumb', 'ztar': 'bdist_dumb', 'tar': 'bdist_dumb', - 'zip': 'bdist_dumb', } + 'zip': 'bdist_dumb', + 'rpm': 'bdist_rpm', + } + # The following commands do not take a format option from bdist + no_format_option = ( 'bdist_rpm', ) def initialize_options (self): self.format = None @@ -63,8 +67,9 @@ raise DistutilsOptionError, \ "invalid archive format '%s'" % self.format - sub_cmd = self.find_peer (cmd_name) - sub_cmd.set_option ('format', self.format) + if cmd_name not in self.no_format_option: + sub_cmd = self.find_peer (cmd_name) + sub_cmd.set_option ('format', self.format) self.run_peer (cmd_name) # run() Index: distutils/command/install.py =================================================================== RCS file: /projects/cvsroot/distutils/distutils/command/install.py,v retrieving revision 1.23 diff -u -r1.23 install.py --- install.py 2000/04/27 01:56:38 1.23 +++ install.py 2000/04/27 09:29:38 @@ -12,6 +12,7 @@ from distutils import sysconfig from distutils.util import write_file, native_path, subst_vars, change_root from distutils.errors import DistutilsOptionError +from glob import glob INSTALL_SCHEMES = { 'unix_prefix': { @@ -82,9 +83,11 @@ #('install-man=', None, "directory for Unix man pages"), #('install-html=', None, "directory for HTML documentation"), #('install-info=', None, "directory for GNU info files"), - ] + ('record', None, + "make a record of installation")] + # 'sub_commands': a list of commands this command might have to run # to get its work done. Each command is represented as a tuple # (func, command) where 'func' is a function to call that returns @@ -141,6 +144,7 @@ #self.install_html = None #self.install_info = None + self.record_install = None def finalize_options (self): @@ -267,7 +271,8 @@ from distutils.fancy_getopt import longopt_xlate print msg + ":" for opt in self.user_options: - opt_name = string.translate (opt[0][0:-1], longopt_xlate) + if opt[0][-1] == '=': + opt_name = string.translate (opt[0][0:-1], longopt_xlate) val = getattr (self, opt_name) print " %s: %s" % (opt_name, val) @@ -424,6 +429,24 @@ "Python's module search path (sys.path) -- " + "you'll have to change the search path yourself") % self.install_lib) + + + # write list of installed files, if requested. + if self.record: + outputs = self.get_outputs() + for counter in xrange (len (outputs)): # include ".pyc" and ".pyo" + if outputs[counter][-3:] == ".py": + byte_code = glob(outputs[counter] + '[co]') + outputs.extend(byte_code) + outputs.sort() # just makes it look nicer + if self.root: # strip any package prefix + root_len = len(self.root) + for counter in xrange (len (outputs)): + outputs[counter] = outputs[counter][root_len:] + self.execute(write_file, + ("INSTALLED_FILES", outputs), + "Writing list of installed files") + # run () --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=package_data release = '1' group = 'Development/Libraries' vendor = 'Distutils-SIG' packager = 'Harry Henry Gebel ' doc = ['CHANGES.txt', 'README.txt', 'USAGE.txt', 'doc/', 'examples/', ] changelog = '''\ * Wed Apr 26 2000 Harry Henry Gebel 0.8.2-1 - First test of bdist_rpm''' --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bdist_rpm.py" """distutils.command.bdist_rpm Implements the Distutils 'bdist_rpm' command (create RPM source and binary distributions.""" # created 2000/04/25, Greg Ward __revision__ = "$Id: bdist_dumb.py,v 1.3 2000/04/22 02:51:25 gward Exp $" import os.path import os from distutils.core import Command from distutils.util import mkpath, write_file, remove_tree from distutils.errors import * from string import join class bdist_rpm (Command): description = "create an RPM distribution" user_options = [ ('spec-only', None, "Only regenerate spec file"), ('tar-only', None, "Only generate spec file and tarball"), ('no-remove', None, "Do not remove root owned files"), ('arch=', None, "Build for a specific architecture"), ] def initialize_options (self): self.spec_only = None self.tar_only = None self.no_remove = None self.arch = None # initialize_options() def finalize_options (self): if os.name != 'posix': raise DistutilsPlatformError, \ ("don't know how to create RPM " "distributions on platform %s") % os.name if self.spec_only and self.tar_only: raise DistutilsOptionsError, \ 'Cannot specify both spec-only and tar-only' if os.getuid(): # if not root if self.no_remove: self.warn('no-remave has no effect when not root') self.remove = None else: # if root if self.no_remove: self.remove = None else: self.remove = 1 # finalize_options() def run (self): self._getPackageData() # get packaging info # place spec file in ./redhat directory self.execute(mkpath, ('./redhat',), "Created ./redhat directory") spec_path = './redhat/%s.spec' % self.name self.execute(write_file, (spec_path, self._makeSpecFile()), 'Writing .spec file') if self.spec_only: # stop if requested return # make a .gz distribution sdist = self.find_peer ('sdist') sdist.set_option ('formats', ['gztar']) self.run_peer('sdist') if self.tar_only: # stop if requested return # build package self.announce('Building RPMs') rpm_args = ['rpm', '-ta', '--clean'] if self.arch and self.distribution.has_ext_modules(): rpm_args.append['--target=' + arch] rpm_args.append(self.distribution.get_fullname() + '.tar.gz') self.spawn(rpm_args) if self.remove: # remove generated files self.execute(self._remove_root, (), 'Removing generated files') def _remove_root(self): ''' Remove files generated to support rpm ''' os.unlink('MANIFEST') os.unlink(self.distribution.get_fullname() + '.tar.gz') remove_tree('redhat') def _getPackageData(self): ''' Get data needed to generate spec file, first from the DistributionMetadata class, then from the package_data file, which is Python code read with execfile() ''' package_type = 'rpm' # read in package data, if any if os.path.exists('package_data'): try: exec(open('package_data')) except: raise DistutilsOptionError, 'Error in package data file' # set instance variables, supplying default value if not provided in # package data file vars = locals().keys() if 'name' in vars: self.name = name else: self.name = self.distribution.get_name() if 'version' in vars: self.version = version else: self.version = self.distribution.get_version() if 'summary' in vars: self.summary = summary else: self.summary = self.distribution.get_description() if 'description' in vars: self.description = description else: self.description = self.distribution.get_long_description() if 'summaries' in vars: self.summaries = summaries else: self.summaries = {} if 'descriptions' in vars: self.descriptions = descriptions else: self.descriptions = {} if 'copyright' in vars: self.copyright = copyright else: self.copyright = self.distribution.get_licence() if 'release' in vars: self.release = release else: self.release = '1' if 'group' in vars: self.group = group else: self.group = 'Applications' if 'vendor' in vars: self.vendor = vendor else: self.vendor = None if 'packager' in vars: self.packager = packager else: self.packager = None if 'url' in vars: self.url = url else: self.url = self.distribution.get_url() if 'doc' in vars: self.doc = join(doc, ' ') else: self.doc = None if 'changelog' in vars: self.changelog = changelog else: self.changelog = None def _makeSpecFile(self): ''' Generate an RPM spec file ''' spec_file = [ '%define name ' + self.name, '%define version ' + self.version, '%define release ' + self.release, '', 'Summary: ' + self.summary, ] # put locale summaries into spec file for locale in self.summaries.keys(): spec_file.append('Summary(%s): %s' % (locale, self.summaries[locale])) spec_file.extend([ 'Name: %{name}', 'Version: %{version}', 'Release: %{release}', 'Source0: %{name}-%{version}.tar.gz', 'Copyright: ' + self.copyright, 'Group: ' + self.group, 'BuildRoot: %{_tmppath}/%{name}-buildroot', 'Prefix: %{_prefix}', ]) if not self.distribution.has_ext_modules(): spec_file.append('BuildArchitectures: noarch') if self.vendor: spec_file.append('Vendor: ' + self.vendor) if self.packager: spec_file.append('Packager: ' + self.packager) if self.url: spec_file.append('Url: ' + self.url) spec_file.extend([ '', '%description', self.description]) # put locale descriptions into spec file for locale in self.descriptions.keys(): spec_file.extend([ '', '%description -l ' + locale, self.descriptions[locale], ]) spec_file.extend([ '', '%prep', '%setup', '', '%build', 'python setup.py build', '', '%install', 'python setup.py install --root=$RPM_BUILD_ROOT ' '--record', '', '%clean', 'rm -rf $RPM_BUILD_ROOT', 'rm -f INSTALLED_FILES', '', '%files -f INSTALLED_FILES', '%defattr(-,root,root)', ]) if self.doc: spec_file.append('%doc ' + self.doc) if self.changelog: spec_file.extend([ '', '%changelog', self.changelog ]) return spec_file # run() --OBd5C1Lgu00Gd/Tn-- From calvin@cs.uni-sb.de Thu Apr 27 15:30:33 2000 From: calvin@cs.uni-sb.de (Bastian Kleineidam) Date: Thu, 27 Apr 2000 16:30:33 +0200 (CEST) Subject: [Distutils] install_scripts and install_data commands Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1619424764-955431714-956845833=:19074 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I wrote a patch for the above commands. Both commands derive from install_misc, which copies some files to a given directory and is defined in cmd.py. With the attached patch you can now have "scripts=[...]" and "data=[...]" attributes in setup.py. By the way: I was not able to TeX the documentation because I found no howto.cls file (the files are using \documentclass{howto}). There should be a make file to compile all the various .tex files. Bastian -- Bastian Kleineidam -- Just do it. Use Linux. .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^ --1619424764-955431714-956845833=:19074 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="scriptsdata.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="scriptsdata.patch" ZGlmZiAtYyAtciAtLWlnbm9yZS1hbGwtc3BhY2UgLS1leGNsdWRlPSoucHlj IC1OIGRpc3R1dGlscy5vcmlnL2Rpc3R1dGlscy9jbWQucHkgZGlzdHV0aWxz LnBhdGNoZWQvZGlzdHV0aWxzL2NtZC5weQ0KKioqIGRpc3R1dGlscy5vcmln L2Rpc3R1dGlscy9jbWQucHkJU3VuIEFwciAxNiAwMDoxNTowNyAyMDAwDQot LS0gZGlzdHV0aWxzLnBhdGNoZWQvZGlzdHV0aWxzL2NtZC5weQlUaHUgQXBy IDI3IDE1OjM2OjMwIDIwMDANCioqKioqKioqKioqKioqKg0KKioqIDM4NCwz ODkgKioqKg0KLS0tIDM4NCw0MTYgLS0tLQ0KICANCiAgIyBjbGFzcyBDb21t YW5kDQogIA0KKyBjbGFzcyBpbnN0YWxsX21pc2MoQ29tbWFuZCk6DQorICAg ICAiIiJDb21tb24gYmFzZSBjbGFzcyBmb3IgaW5zdGFsbGluZyBzb21lIGZp bGVzIGluIGEgc3ViZGlyZWN0b3J5DQorICAgICBDdXJyZW50bHkgdXNlZCBi eSBpbnN0YWxsX2RhdGEgYW5kIGluc3RhbGxfc2NyaXB0cw0KKyAgICAgIiIi DQorICAgICB1c2VyX29wdGlvbnMgPSBbKCdpbnN0YWxsLWRpcj0nLCAnZCcs ICJkaXJlY3RvcnkgdG8gaW5zdGFsbCB0aGUgZmlsZXMgdG8iKV0NCisgDQor ICAgICBkZWYgaW5pdGlhbGl6ZV9vcHRpb25zIChzZWxmKToNCisgICAgICAg ICBzZWxmLmluc3RhbGxfZGlyID0gTm9uZQ0KKyAgICAgICAgIHNlbGYub3V0 ZmlsZXMgPSBOb25lDQorIA0KKyAgICAgZGVmIF9pbnN0YWxsX2Rpcl9mcm9t KHNlbGYsIGRpcm5hbWUpOg0KKyAgICAgICAgIHNlbGYuc2V0X3VuZGVmaW5l ZF9vcHRpb25zKCdpbnN0YWxsJywgKGRpcm5hbWUsICdpbnN0YWxsX2Rpcicp KQ0KKyANCisgICAgIGRlZiBfY29weWRhdGEoc2VsZiwgZmlsZWxpc3QpOg0K KyAgICAgICAgIHNlbGYub3V0ZmlsZXMgPSBbXQ0KKyAgICAgICAgIGlmIG5v dCBmaWxlbGlzdDoNCisgICAgICAgICAgICAgcmV0dXJuDQorICAgICAgICAg c2VsZi5ta3BhdGgoc2VsZi5pbnN0YWxsX2RpcikNCisgICAgICAgICBmb3Ig ZiBpbiBmaWxlbGlzdDoNCisgICAgICAgICAgICAgc2VsZi5vdXRmaWxlcy5h cHBlbmQoc2VsZi5jb3B5X2ZpbGUgKGYsIHNlbGYuaW5zdGFsbF9kaXIpKQ0K KyANCisgICAgIGRlZiBfb3V0cHV0ZGF0YShzZWxmLCBmaWxlbGlzdCk6DQor ICAgICAgICAgaWYgc2VsZi5vdXRmaWxlcyBpcyBub3QgTm9uZToNCisgICAg ICAgICAgICAgcmV0dXJuIHNlbGYub3V0ZmlsZXMNCisgICAgICAgICByZXR1 cm4gbWFwKGxhbWJkYSB4OiBvcy5wYXRoLmpvaW4oc2VsZi5pbnN0YWxsX2Rp ciwgeCksIGZpbGVsaXN0KQ0KKyANCisgDQogIA0KICBpZiBfX25hbWVfXyA9 PSAiX19tYWluX18iOg0KICAgICAgcHJpbnQgIm9rIg0KZGlmZiAtYyAtciAt LWlnbm9yZS1hbGwtc3BhY2UgLS1leGNsdWRlPSoucHljIC1OIGRpc3R1dGls cy5vcmlnL2Rpc3R1dGlscy9jb21tYW5kL19faW5pdF9fLnB5IGRpc3R1dGls cy5wYXRjaGVkL2Rpc3R1dGlscy9jb21tYW5kL19faW5pdF9fLnB5DQoqKiog ZGlzdHV0aWxzLm9yaWcvZGlzdHV0aWxzL2NvbW1hbmQvX19pbml0X18ucHkJ RnJpIE1hciAzMSAwNToxNDo1MSAyMDAwDQotLS0gZGlzdHV0aWxzLnBhdGNo ZWQvZGlzdHV0aWxzL2NvbW1hbmQvX19pbml0X18ucHkJVGh1IEFwciAyNyAx NTozNzoxMSAyMDAwDQoqKioqKioqKioqKioqKioNCioqKiAxMSwxNiAqKioq DQotLS0gMTEsMTggLS0tLQ0KICAgICAgICAgICAgICdidWlsZF9jbGliJywN CiAgICAgICAgICAgICAnaW5zdGFsbCcsDQogICAgICAgICAgICAgJ2luc3Rh bGxfbGliJywNCisgICAgICAgICAgICAnaW5zdGFsbF9zY3JpcHRzJywNCisg ICAgICAgICAgICAnaW5zdGFsbF9kYXRhJywNCiAgICAgICAgICAgICAnY2xl YW4nLA0KICAgICAgICAgICAgICdzZGlzdCcsDQogICAgICAgICAgICAgJ2Jk aXN0JywNCmRpZmYgLWMgLXIgLS1pZ25vcmUtYWxsLXNwYWNlIC0tZXhjbHVk ZT0qLnB5YyAtTiBkaXN0dXRpbHMub3JpZy9kaXN0dXRpbHMvY29tbWFuZC9p bnN0YWxsLnB5IGRpc3R1dGlscy5wYXRjaGVkL2Rpc3R1dGlscy9jb21tYW5k L2luc3RhbGwucHkNCioqKiBkaXN0dXRpbHMub3JpZy9kaXN0dXRpbHMvY29t bWFuZC9pbnN0YWxsLnB5CVRodSBBcHIgMjcgMDM6NTY6MzggMjAwMA0KLS0t IGRpc3R1dGlscy5wYXRjaGVkL2Rpc3R1dGlscy9jb21tYW5kL2luc3RhbGwu cHkJVGh1IEFwciAyNyAxNTo1NTowNCAyMDAwDQoqKioqKioqKioqKioqKioN CioqKiA5MCw5NiAqKioqDQogICAgICAjIChmdW5jLCBjb21tYW5kKSB3aGVy ZSAnZnVuYycgaXMgYSBmdW5jdGlvbiB0byBjYWxsIHRoYXQgcmV0dXJucw0K ICAgICAgIyB0cnVlIGlmICdjb21tYW5kJyAodGhlIHN1Yi1jb21tYW5kIG5h bWUsIGEgc3RyaW5nKSBuZWVkcyB0byBiZQ0KICAgICAgIyBydW4uICBJZiAn ZnVuYycgaXMgTm9uZSwgYXNzdW1lIHRoYXQgJ2NvbW1hbmQnIG11c3QgYWx3 YXlzIGJlIHJ1bi4NCiEgICAgIHN1Yl9jb21tYW5kcyA9IFsoTm9uZSwgJ2lu c3RhbGxfbGliJyldDQogIA0KICANCiAgICAgIGRlZiBpbml0aWFsaXplX29w dGlvbnMgKHNlbGYpOg0KLS0tIDkwLDk5IC0tLS0NCiAgICAgICMgKGZ1bmMs IGNvbW1hbmQpIHdoZXJlICdmdW5jJyBpcyBhIGZ1bmN0aW9uIHRvIGNhbGwg dGhhdCByZXR1cm5zDQogICAgICAjIHRydWUgaWYgJ2NvbW1hbmQnICh0aGUg c3ViLWNvbW1hbmQgbmFtZSwgYSBzdHJpbmcpIG5lZWRzIHRvIGJlDQogICAg ICAjIHJ1bi4gIElmICdmdW5jJyBpcyBOb25lLCBhc3N1bWUgdGhhdCAnY29t bWFuZCcgbXVzdCBhbHdheXMgYmUgcnVuLg0KISAgICAgc3ViX2NvbW1hbmRz ID0gWyhOb25lLCAnaW5zdGFsbF9saWInKSwNCiEgICAgICAgICAgICAgICAg ICAgICAoTm9uZSwgJ2luc3RhbGxfc2NyaXB0cycpLA0KISAJCSAgICAoTm9u ZSwgJ2luc3RhbGxfZGF0YScpLA0KISAgICAgICAgICAgICAgICAgICAgXQ0K ICANCiAgDQogICAgICBkZWYgaW5pdGlhbGl6ZV9vcHRpb25zIChzZWxmKToN CmRpZmYgLWMgLXIgLS1pZ25vcmUtYWxsLXNwYWNlIC0tZXhjbHVkZT0qLnB5 YyAtTiBkaXN0dXRpbHMub3JpZy9kaXN0dXRpbHMvY29tbWFuZC9pbnN0YWxs X2RhdGEucHkgZGlzdHV0aWxzLnBhdGNoZWQvZGlzdHV0aWxzL2NvbW1hbmQv aW5zdGFsbF9kYXRhLnB5DQoqKiogZGlzdHV0aWxzLm9yaWcvZGlzdHV0aWxz L2NvbW1hbmQvaW5zdGFsbF9kYXRhLnB5CVRodSBKYW4gIDEgMDE6MDA6MDAg MTk3MA0KLS0tIGRpc3R1dGlscy5wYXRjaGVkL2Rpc3R1dGlscy9jb21tYW5k L2luc3RhbGxfZGF0YS5weQlUaHUgQXByIDI3IDE1OjM1OjQ1IDIwMDANCioq KioqKioqKioqKioqKg0KKioqIDAgKioqKg0KLS0tIDEsMTQgLS0tLQ0KKyBm cm9tIGRpc3R1dGlscy5jbWQgaW1wb3J0IGluc3RhbGxfbWlzYw0KKyANCisg Y2xhc3MgaW5zdGFsbF9kYXRhIChpbnN0YWxsX21pc2MpOg0KKyANCisgICAg IGRlc2NyaXB0aW9uID0gImluc3RhbGwgZGF0YSBmaWxlcyINCisgDQorICAg ICBkZWYgZmluYWxpemVfb3B0aW9ucyAoc2VsZik6DQorICAgICAgICAgc2Vs Zi5faW5zdGFsbF9kaXJfZnJvbSgnaW5zdGFsbF9kYXRhJykNCisgDQorICAg ICBkZWYgcnVuIChzZWxmKToNCisgICAgICAgICBzZWxmLl9jb3B5ZGF0YShz ZWxmLmRpc3RyaWJ1dGlvbi5kYXRhKQ0KKyANCisgICAgIGRlZiBnZXRfb3V0 cHV0cyhzZWxmKToNCisgICAgICAgICByZXR1cm4gc2VsZi5fb3V0cHV0ZGF0 YShzZWxmLmRpc3RyaWJ1dGlvbi5kYXRhKQ0KZGlmZiAtYyAtciAtLWlnbm9y ZS1hbGwtc3BhY2UgLS1leGNsdWRlPSoucHljIC1OIGRpc3R1dGlscy5vcmln L2Rpc3R1dGlscy9jb21tYW5kL2luc3RhbGxfc2NyaXB0cy5weSBkaXN0dXRp bHMucGF0Y2hlZC9kaXN0dXRpbHMvY29tbWFuZC9pbnN0YWxsX3NjcmlwdHMu cHkNCioqKiBkaXN0dXRpbHMub3JpZy9kaXN0dXRpbHMvY29tbWFuZC9pbnN0 YWxsX3NjcmlwdHMucHkJVGh1IEphbiAgMSAwMTowMDowMCAxOTcwDQotLS0g ZGlzdHV0aWxzLnBhdGNoZWQvZGlzdHV0aWxzL2NvbW1hbmQvaW5zdGFsbF9z Y3JpcHRzLnB5CVRodSBBcHIgMjcgMTU6MzU6NDAgMjAwMA0KKioqKioqKioq KioqKioqDQoqKiogMCAqKioqDQotLS0gMSwxNSAtLS0tDQorIGZyb20gZGlz dHV0aWxzLmNtZCBpbXBvcnQgaW5zdGFsbF9taXNjDQorIA0KKyBjbGFzcyBp bnN0YWxsX3NjcmlwdHMoaW5zdGFsbF9taXNjKToNCisgDQorICAgICBkZXNj cmlwdGlvbiA9ICJpbnN0YWxsIHNjcmlwdHMiDQorICAgICB1c2VyX29wdGlv bnMgPSBbKCdpbnN0YWxsLWRpcj0nLCAnZCcsICJkaXJlY3RvcnkgdG8gaW5z dGFsbCB0byIpXQ0KKyANCisgICAgIGRlZiBmaW5hbGl6ZV9vcHRpb25zIChz ZWxmKToNCisgICAgICAgICBzZWxmLl9pbnN0YWxsX2Rpcl9mcm9tKCdpbnN0 YWxsX3NjcmlwdHMnKQ0KKyANCisgICAgIGRlZiBydW4gKHNlbGYpOg0KKyAg ICAgICAgIHNlbGYuX2NvcHlkYXRhKHNlbGYuZGlzdHJpYnV0aW9uLnNjcmlw dHMpDQorIA0KKyAgICAgZGVmIGdldF9vdXRwdXRzKHNlbGYpOg0KKyAgICAg ICAgIHJldHVybiBzZWxmLl9vdXRwdXRkYXRhKHNlbGYuZGlzdHJpYnV0aW9u LnNjcmlwdHMpDQpkaWZmIC1jIC1yIC0taWdub3JlLWFsbC1zcGFjZSAtLWV4 Y2x1ZGU9Ki5weWMgLU4gZGlzdHV0aWxzLm9yaWcvZGlzdHV0aWxzL2Rpc3Qu cHkgZGlzdHV0aWxzLnBhdGNoZWQvZGlzdHV0aWxzL2Rpc3QucHkNCioqKiBk aXN0dXRpbHMub3JpZy9kaXN0dXRpbHMvZGlzdC5weQlXZWQgQXByIDI2IDA0 OjI2OjU1IDIwMDANCi0tLSBkaXN0dXRpbHMucGF0Y2hlZC9kaXN0dXRpbHMv ZGlzdC5weQlUaHUgQXByIDI3IDE1OjU0OjA2IDIwMDANCioqKioqKioqKioq KioqKg0KKioqIDE0OCwxNTMgKioqKg0KLS0tIDE0OCwxNTUgLS0tLQ0KICAg ICAgICAgIHNlbGYuZXh0X3BhY2thZ2UgPSBOb25lDQogICAgICAgICAgc2Vs Zi5pbmNsdWRlX2RpcnMgPSBOb25lDQogICAgICAgICAgc2VsZi5leHRyYV9w YXRoID0gTm9uZQ0KKyAgICAgICAgIHNlbGYuc2NyaXB0cyA9IE5vbmUNCisg ICAgICAgICBzZWxmLmRhdGEgPSBOb25lDQogIA0KICAgICAgICAgICMgQW5k IG5vdyBpbml0aWFsaXplIGJvb2trZWVwaW5nIHN0dWZmIHRoYXQgY2FuJ3Qg YmUgc3VwcGxpZWQgYnkNCiAgICAgICAgICAjIHRoZSBjYWxsZXIgYXQgYWxs LiAgJ2NvbW1hbmRfb2JqJyBtYXBzIGNvbW1hbmQgbmFtZXMgdG8NCmRpZmYg LWMgLXIgLS1pZ25vcmUtYWxsLXNwYWNlIC0tZXhjbHVkZT0qLnB5YyAtTiBk aXN0dXRpbHMub3JpZy9kb2MvZGlzdC9kaXN0LnRleCBkaXN0dXRpbHMucGF0 Y2hlZC9kb2MvZGlzdC9kaXN0LnRleA0KKioqIGRpc3R1dGlscy5vcmlnL2Rv Yy9kaXN0L2Rpc3QudGV4CVR1ZSBBcHIgMjUgMDQ6NTc6MzYgMjAwMA0KLS0t IGRpc3R1dGlscy5wYXRjaGVkL2RvYy9kaXN0L2Rpc3QudGV4CVRodSBBcHIg MjcgMTU6NTE6NTAgMjAwMA0KKioqKioqKioqKioqKioqDQoqKiogNjUyLDY1 NyAqKioqDQotLS0gNjUyLDY3MiAtLS0tDQogIA0KICBcc3Vic2VjdGlvbntJ bnN0YWxsaW5nIG1vZHVsZXM6IHRoZSBccHJvdGVjdFxjb21tYW5ke2luc3Rh bGx9IGNvbW1hbmQgZmFtaWx5fQ0KICBcbGFiZWx7c2VjOmluc3RhbGwtY21k fQ0KKyBUaGUgaW5zdGFsbCBjb21tYW5kIGVuc3VyZXMgdGhhdCB0aGUgYnVp bGQgY29tbWFuZHMgaGF2ZSBiZWVuIHJ1biBhbmQgdGhlbg0KKyBydW5zIHRo ZSBzdWJjb21tYW5kcyBcY29tbWFuZHtpbnN0YWxsXF9saWJ9LA0KKyBcY29t bWFuZHtpbnN0YWxsXF9kYXRhfSBhbmQNCisgXGNvbW1hbmR7aW5zdGFsbFxf c2NyaXB0c30uDQorIA0KKyBcc3Vic3Vic2VjdGlvbntccHJvdGVjdFxjb21t YW5ke2luc3RhbGxcX2xpYn19DQorIFxsYWJlbHtzZWM6aW5zdGFsbC1saWIt Y21kfQ0KKyANCisgXHN1YnN1YnNlY3Rpb257XHByb3RlY3RcY29tbWFuZHtp bnN0YWxsXF9kYXRhfX0NCisgXGxhYmVse3NlYzppbnN0YWxsLWRhdGEtY21k fQ0KKyBUaGlzIGNvbW1hbmQgaW5zdGFsbHMgYWxsIGRhdGEgZmlsZXMgb2Yg dGhlIGRpc3RyaWJ1dGlvbi4NCisgDQorIFxzdWJzdWJzZWN0aW9ue1xwcm90 ZWN0XGNvbW1hbmR7aW5zdGFsbFxfc2NyaXB0c319DQorIFxsYWJlbHtzZWM6 aW5zdGFsbC1zY3JpcHRzLWNtZH0NCisgVGhpcyBjb21tYW5kIGluc3RhbGxz IGFsbCBzY3JpcHQgZmlsZXMgb2YgdGhlIGRpc3RyaWJ1dGlvbi4NCiAgDQog IA0KICBcc3Vic2VjdGlvbntDbGVhbmluZyB1cDogdGhlIFxwcm90ZWN0XGNv bW1hbmR7Y2xlYW59IGNvbW1hbmR9DQo= --1619424764-955431714-956845833=:19074-- From mwa@gate.net Thu Apr 27 21:07:51 2000 From: mwa@gate.net (Mark W. Alexander) Date: Thu, 27 Apr 2000 16:07:51 -0400 (EDT) Subject: [Distutils] bdist_rpm In-Reply-To: <20000426211143.A747@beelzebub> Message-ID: After poking and proding in all the places rpmrc is supposed to be looked for..... rpm --showrc (duh.) The first section shows the architecture info. AND, rpm CAN be used on Solaris, BSD, HP-UX, whatever. It's just a complete pain, mostly trying to get it to know about all the dependencies that already live on the box. You're better off with a bdist routine for each package type. Mark Alexander mwa@gate.net On Wed, 26 Apr 2000, Greg Ward wrote: > Date: Wed, 26 Apr 2000 21:11:43 -0400 > From: Greg Ward > To: distutils-sig@python.org > Subject: Re: [Distutils] bdist_rpm > > On 25 April 2000, Mark W. Alexander said: > > Since bdist_rpm implies RPM-only, how about using the > > default architecture from the rpmrc file? > > 'Cause I totally forgot about the rpmrc file, of course! Hmmm... I > don't see anything in my /etc/rpmrc which would set the architecture > string, though. Does RPM just figure it out for the current platform? > > Also, is there any sort of standard emerging for better platform strings > in RPM filenames? "foo-1.3.4-1.i386.rpm" doesn't really cut it if you > want to live in a world where Solaris, Linux, and *BSD all use RPMs. > (Yes yes, I know they *don't*, but it's a nice idea...) > > Greg > > PS. as I mentioned earlier, the "noarch" distinction is easily handled: > "if not self.distribution.has_ext_modules()" somewhere in the bdist_rpm > command. > > -- > Greg Ward - Linux geek gward@python.net > http://starship.python.net/~gward/ > We have always been at war with Oceania. > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://www.python.org/mailman/listinfo/distutils-sig >