From mdehoon@ims.u-tokyo.ac.jp Thu May 1 00:35:02 2003 From: mdehoon@ims.u-tokyo.ac.jp (Michiel Jan Laurens de Hoon) Date: Wed Apr 30 23:35:02 2003 Subject: [Distutils] Switching off optimization for python setup.py config Message-ID: <3EB096B1.6070105@ims.u-tokyo.ac.jp> Dear pythoneers, Recently I ran into a bug in Numerical Python's eigenvalues function, causing it to hang on Cygwin. The bug is caused by Numerical Python being compiled with optimization, while a number of routines (the dlamc* functions in dlapack_lite.c) should be compiled without optimization to function properly (as described in the lapack documentation). In reading the distutils archives, it seems that the issue of changing optimization levels and other compiler flags has been raised before. From what I understand, the current version of distutils does not allow to change the optimization level. The problem seems to be that some compiler arguments are required for an extension module to work with Python, and cannot just be changed (for example, my Makefile has OPT=-DNDEBUG -g -O3 -Wall -Wstrict-prototypes in it, which is more than just optimization flags). Now what the dlamc* functions are really doing is to find out some machine parameters before the actual numerical routines are executed. In today's world of autoconf, automake, and python setup.py config, I would think that it makes more sense to let distutils' config step figure out the machine parameters, and hardwire the results into the source code with some #define's. This can be achieved by letting python setup.py config run the dlamc* routines. However, for this we need to switch off optimization for the trial compilations and runs done by python setup.py config. Is this possible with the current version of distutils? If not, would it be worthwhile to add this to distutils? We have more freedom in changing compiler switches for trial compilations than for the actual extension module, and I would think that this would be useful for cases other than Numerical Python. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon From mal@lemburg.com Thu May 1 10:05:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu May 1 09:05:02 2003 Subject: [Distutils] Switching off optimization for python setup.py config In-Reply-To: <3EB096B1.6070105@ims.u-tokyo.ac.jp> References: <3EB096B1.6070105@ims.u-tokyo.ac.jp> Message-ID: <3EB11B35.204@lemburg.com> Michiel Jan Laurens de Hoon wrote: > Dear pythoneers, > > Recently I ran into a bug in Numerical Python's eigenvalues function, > causing it to hang on Cygwin. The bug is caused by Numerical Python > being compiled with optimization, while a number of routines (the dlamc* > functions in dlapack_lite.c) should be compiled without optimization to > function properly (as described in the lapack documentation). > > In reading the distutils archives, it seems that the issue of changing > optimization levels and other compiler flags has been raised before. > From what I understand, the current version of distutils does not allow > to change the optimization level. The problem seems to be that some > compiler arguments are required for an extension module to work with > Python, and cannot just be changed (for example, my Makefile has > OPT=-DNDEBUG -g -O3 -Wall -Wstrict-prototypes in it, which is more than > just optimization flags). > > Now what the dlamc* functions are really doing is to find out some > machine parameters before the actual numerical routines are executed. In > today's world of autoconf, automake, and python setup.py config, I would > think that it makes more sense to let distutils' config step figure out > the machine parameters, and hardwire the results into the source code > with some #define's. > > This can be achieved by letting python setup.py config run the dlamc* > routines. However, for this we need to switch off optimization for the > trial compilations and runs done by python setup.py config. Is this > possible with the current version of distutils? If not, would it be > worthwhile to add this to distutils? We have more freedom in changing > compiler switches for trial compilations than for the actual extension > module, and I would think that this would be useful for cases other than > Numerical Python. You can use the distutils.command.config command class to write configuration and test compilation methods. These have complete control over the compiler being used, so switching off optimization for the purpose of configuration should be possible. The config command is still way from being complete and not all that useful by itself, but it provides a nice hook to integrate and add your own configuration tools. For an example on what can be done, see mxSetup.py in the eGenix mx Extensions tar-balls. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 01 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 54 days left From Jack.Jansen@oratrix.com Thu May 1 16:57:01 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu May 1 15:57:01 2003 Subject: [Distutils] Switching off optimization for python setup.py config In-Reply-To: <3EB11B35.204@lemburg.com> Message-ID: <05F0C51C-7C0F-11D7-BD7E-000A27B19B96@oratrix.com> On donderdag, mei 1, 2003, at 15:03 Europe/Amsterdam, M.-A. Lemburg wrote: > You can use the distutils.command.config command class to write > configuration and test compilation methods. These have complete > control over the compiler being used, so switching off optimization > for the purpose of configuration should be possible. Does this work on non-unix platforms? MacOS9 is on the way out (it definitely won't work there), but I wouldn't be surprised if stuff like this also won't work on Windows or BeOS or whatever. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mal@lemburg.com Thu May 1 17:19:04 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu May 1 16:19:04 2003 Subject: [Distutils] Switching off optimization for python setup.py config In-Reply-To: <05F0C51C-7C0F-11D7-BD7E-000A27B19B96@oratrix.com> References: <05F0C51C-7C0F-11D7-BD7E-000A27B19B96@oratrix.com> Message-ID: <3EB18100.8040807@lemburg.com> Jack Jansen wrote: > > On donderdag, mei 1, 2003, at 15:03 Europe/Amsterdam, M.-A. Lemburg wrote: > >> You can use the distutils.command.config command class to write >> configuration and test compilation methods. These have complete >> control over the compiler being used, so switching off optimization >> for the purpose of configuration should be possible. > > > Does this work on non-unix platforms? MacOS9 is on the way out (it > definitely won't work there), but I wouldn't be surprised if stuff like > this also won't work on Windows or BeOS or whatever. If you mean the config command, yes, this also works on Windows. I use it to check for C APIs and to find locations of C libs and header files. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 01 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 54 days left From slash@dotnetslash.net Thu May 1 20:21:20 2003 From: slash@dotnetslash.net (Mark W. Alexander) Date: Thu May 1 19:21:20 2003 Subject: [Distutils] Switching off optimization for python setup.py config In-Reply-To: <3EB18100.8040807@lemburg.com> Message-ID: On Thu, 1 May 2003, M.-A. Lemburg wrote: > Jack Jansen wrote: > > > > On donderdag, mei 1, 2003, at 15:03 Europe/Amsterdam, M.-A. Lemburg wrote: > > > >> You can use the distutils.command.config command class to write > >> configuration and test compilation methods. These have complete > >> control over the compiler being used, so switching off optimization > >> for the purpose of configuration should be possible. > > > > > > Does this work on non-unix platforms? MacOS9 is on the way out (it > > definitely won't work there), but I wouldn't be surprised if stuff like > > this also won't work on Windows or BeOS or whatever. > > If you mean the config command, yes, this also works on Windows. > I use it to check for C APIs and to find locations of C libs > and header files. Hmm. Then would this also work for making a setup.py that was capable of cross-compiling to other targets? I've long been thinking the combination of Distutils, the catalog and a cross-compiler setup on the server would be able to deliver native binary packages from a source repository. Take that, CPAN! mwa -- Mark W. Alexander slash@dotnetslash.net From mal@lemburg.com Fri May 2 05:50:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri May 2 04:50:02 2003 Subject: [Distutils] AssertionError when building rpm under RedHat 9.1 In-Reply-To: <20030428234119.0e07d475.nieder@mail.ru> References: <20030428234119.0e07d475.nieder@mail.ru> Message-ID: <3EB230EB.9000506@lemburg.com> Ricardo Niederberger Cabral wrote: >>From distutils __version__ = "1.0.3": > > File "distutils/command/bdist_rpm.py", line 316, in run > assert len(rpms) == 1, \ > AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] > > I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm. > Would it be possible to change from "assert len(rpms) == 1" to "assert len(rpms) >= 1" ? Since rpmbuild from RH seems to always generate this extra -debuginfo rpm. Could you submit a bug report / patch for this to SourceForge ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 02 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 53 days left From nicodemus@icablenet.com.br Mon May 5 22:12:01 2003 From: nicodemus@icablenet.com.br (Nicodemus) Date: Mon May 5 21:12:01 2003 Subject: [Distutils] setup.py not being included with sdist Message-ID: <002c01c26e30$2875ce90$0200000a@nicodemus> Hail! I've been using distutils to create distributions of some scripts and libraries, and everything works as expected, except that the setup.py file is not included in the source distribution. For example, if I use the sample program from the python docs: # setup.py from distutils.core import setup setup(name="foo", version="1.0", py_modules=["foo"]) and run "python setup install", it creates a zipfile named "foo-1.0.zip", that contains the following files: foo-1.0/ foo-1.0/foo.py foo-1.0/PKG-INFO Shouldn't setup.py be included with the distribution? What am I doing wrong? Thanks in advance, Nicodemus. From nieder@mail.ru Mon May 5 22:59:01 2003 From: nieder@mail.ru (Ricardo Niederberger Cabral) Date: Mon May 5 21:59:01 2003 Subject: [Distutils] setup.py not being included with sdist In-Reply-To: <002c01c26e30$2875ce90$0200000a@nicodemus> References: <002c01c26e30$2875ce90$0200000a@nicodemus> Message-ID: <20030505225911.26653d4f.nieder@mail.ru> On Mon, 7 Oct 2002 15:34:22 -0300 "Nicodemus" wrote: > I've been using distutils to create distributions of some scripts and > libraries, and everything works as expected, except that the setup.py file > is not included in the source distribution. [...] > and run "python setup install", it creates a zipfile named "foo-1.0.zip", > that contains the following files: > foo-1.0/ > foo-1.0/foo.py > foo-1.0/PKG-INFO > Shouldn't setup.py be included with the distribution? What am I doing wrong? try: $ python setup.py sdist If even after that setup.py doesn't end up on your source tarball, you may, as a last resort, include setup.py on your MANIFEST.in file. Best regards, -- rnc From nicodemus@globalite.com.br Mon May 5 23:12:01 2003 From: nicodemus@globalite.com.br (Nicodemus) Date: Mon May 5 22:12:01 2003 Subject: [Distutils] setup.py not being included with sdist In-Reply-To: <20030505225911.26653d4f.nieder@mail.ru> References: <002c01c26e30$2875ce90$0200000a@nicodemus> <20030505225911.26653d4f.nieder@mail.ru> Message-ID: <3EB719B8.7070100@globalite.com.br> Ricardo Niederberger Cabral wrote: >On Mon, 7 Oct 2002 15:34:22 -0300 >"Nicodemus" wrote: > > > >>I've been using distutils to create distributions of some scripts and >>libraries, and everything works as expected, except that the setup.py file >>is not included in the source distribution. >> >> >[...] > > >>and run "python setup install", it creates a zipfile named "foo-1.0.zip", >>that contains the following files: >>foo-1.0/ >>foo-1.0/foo.py >>foo-1.0/PKG-INFO >>Shouldn't setup.py be included with the distribution? What am I doing wrong? >> >> > >try: >$ python setup.py sdist > >If even after that setup.py doesn't end up on your source tarball, you may, as a last resort, include setup.py on your MANIFEST.in file. > >Best regards, > Jesus, I sent that message last year! 8P That was a mistake, I was using "python setup.py sdist", sorry about that. Also, the environment was Windows 2000. To solve this, I used the MANIFEST.in file as you suggested. Regards, Nicodemus. From fog@initd.org Thu May 8 08:30:01 2003 From: fog@initd.org (Federico Di Gregorio) Date: Thu May 8 07:30:01 2003 Subject: [Distutils] multiple args in setup.cfg lines Message-ID: <1052393382.6314.11.camel@momo.initd.org> --=-4GoqRRzmoKRg8zkHUmB6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi *, this is my first post to this list, and i did not found a FAQ anyware, so just tell me to go RTFM if this is a know problem. To put it shortly i am trying to use a setup.cfg file with the following entry: [build_ext] include_dirs: /usr/include/postgresql /usr/include/postgresql/server that results in: -Iinclude_dirs: /usr/include/postgresql /usr/include/postgresql/server i.e., a missing -I on the second include directory. after reading the source for dist.py i understand why and i can see an easy fix (quote_splitting the line) but maybe there is a reason for not splitting or another (better) way to obtain what i want? anticipated thanks, federico p.s. why setup.cfg does not accept extra_{compile,link}_args? that would have solved my problem, even if in a quite dirty way. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-4GoqRRzmoKRg8zkHUmB6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA+uj+mvcCgrgZGjesRAlMJAJ9DxElCT+HRZyVrw43FFbp/N0kiswCdE/u6 F3OtyZnqzGONHgraKseEhTQ= =/aeQ -----END PGP SIGNATURE----- --=-4GoqRRzmoKRg8zkHUmB6-- From magill@gate.net Mon May 12 04:10:01 2003 From: magill@gate.net (Tim Magill) Date: Mon May 12 03:10:01 2003 Subject: [Distutils] patch for interpreter destination location Message-ID: <20030512000950.F5952@fruitbat.cisco.com> --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm interested in building distribution files in multiple spooling directories for delivery on multiple platforms. In doing so there was no way for me to set the location for the interpreter in the final destination rather than the spooling destination. Enclosed is a patch that allows me to specify the string to be substituted in the "#!" line at the beginning of scripts and a documentation fragment for the new option. Comments? thanks tim --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.diff" Index: Lib/distutils/command/build.py =================================================================== RCS file: /src/python/Lib/distutils/command/build.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 build.py --- Lib/distutils/command/build.py 25 Jan 2003 00:10:42 -0000 1.1.1.1 +++ Lib/distutils/command/build.py 10 May 2003 21:50:11 -0000 @@ -40,6 +40,8 @@ "compile extensions and libraries with debugging information"), ('force', 'f', "forcibly build everything (ignore file timestamps)"), + ('executable=', 'e', + "specify final destination interpreter path (build.py)"), ] boolean_options = ['debug', 'force'] @@ -61,6 +63,7 @@ self.compiler = None self.debug = None self.force = 0 + self.executable = None def finalize_options (self): @@ -93,6 +96,8 @@ self.build_scripts = os.path.join(self.build_base, 'scripts-' + sys.version[0:3]) + if self.executable is None: + self.executable = os.path.normpath(sys.executable) # finalize_options () Index: Lib/distutils/command/build_scripts.py =================================================================== RCS file: /src/python/Lib/distutils/command/build_scripts.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 build_scripts.py --- Lib/distutils/command/build_scripts.py 25 Jan 2003 00:10:42 -0000 1.1.1.1 +++ Lib/distutils/command/build_scripts.py 10 May 2003 21:50:11 -0000 @@ -22,6 +22,7 @@ user_options = [ ('build-dir=', 'd', "directory to \"build\" (copy) to"), ('force', 'f', "forcibly build everything (ignore file timestamps"), + ('executable=', 'e', "specify final destination interpreter path"), ] boolean_options = ['force'] @@ -31,12 +32,14 @@ self.build_dir = None self.scripts = None self.force = None + self.executable = None self.outfiles = None def finalize_options (self): self.set_undefined_options('build', ('build_scripts', 'build_dir'), - ('force', 'force')) + ('force', 'force'), + ('executable', 'executable')) self.scripts = self.distribution.scripts @@ -89,7 +92,7 @@ outf = open(outfile, "w") if not sysconfig.python_build: outf.write("#!%s%s\n" % - (os.path.normpath(sys.executable), + (self.executable, post_interp)) else: outf.write("#!%s%s" % --BI5RvnYi6R4T2M87 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="doc.txt" 3.4 Listing scripts So far we have been dealing with pure and non-pure Python modules, which are usually not run by themselves but imported by scripts. Scripts are files containing Python source code, indended to be started from the command line. Distutils provides two features for scripts. If the first line of the script starts with #! and contains the word ``python'' Distutils adjusts the interpreter location. By default, it is replaced with the current interpreter location. The '--executable=/-e' switch will allow the interpreter path to be explicitly overridden. The scripts option simply is a list of files to be handled in this way. --BI5RvnYi6R4T2M87-- From mal@lemburg.com Mon May 12 06:26:24 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon May 12 05:26:24 2003 Subject: [Distutils] patch for interpreter destination location In-Reply-To: <20030512000950.F5952@fruitbat.cisco.com> References: <20030512000950.F5952@fruitbat.cisco.com> Message-ID: <3EBF6867.8060804@lemburg.com> Tim Magill wrote: > Hi, > > I'm interested in building distribution files in multiple spooling > directories for delivery on multiple platforms. In doing so there was > no way for me to set the location for the interpreter in the final > destination rather than the spooling destination. > > Enclosed is a patch that allows me to specify the string to be > substituted in the "#!" line at the beginning of scripts and a > documentation fragment for the new option. > > Comments? Looks Ok. Please upload it to the SourceForge tracker. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 12 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 43 days left From anthony@interlink.com.au Mon May 12 13:07:05 2003 From: anthony@interlink.com.au (Anthony Baxter) Date: Mon May 12 12:07:05 2003 Subject: [Distutils] distutils reference documentation work in progress Message-ID: <200305121606.h4CG6j906961@localhost.localdomain> I've started on a complete reference for distutils and it's piles and piles of goodies. It's very much a work in progress right now (I doubt it's even completely valid LaTeX yet :) but there's a slab of it done at http://www.interlink.com.au/anthony/tmp/distref_tex.txt (wacky filename because Apache kept sending it as a blah/x-tex rather than as bloody text). It'll be updated fairly regularly as I work on it - it's good fodder for the tram rides to/from work. The documentation is largely based on the voluminous docstrings, with a sprinkling of magic organisational pixie dust. Feedback is more than welcome. Anthony From magill@gate.net Tue May 13 03:34:02 2003 From: magill@gate.net (Tim Magill) Date: Tue May 13 02:34:02 2003 Subject: [Distutils] patch for interpreter destination location In-Reply-To: <3EBF6867.8060804@lemburg.com>; from mal@lemburg.com on Mon, May 12, 2003 at 11:24:55AM +0200 References: <20030512000950.F5952@fruitbat.cisco.com> <3EBF6867.8060804@lemburg.com> Message-ID: <20030512233311.A10696@fruitbat.cisco.com> Ok, done. thanks tim On Mon, May 12, 2003 at 11:24:55AM +0200, M.-A. Lemburg wrote: > Tim Magill wrote: > > Hi, > > > > I'm interested in building distribution files in multiple spooling > > directories for delivery on multiple platforms. In doing so there was > > no way for me to set the location for the interpreter in the final > > destination rather than the spooling destination. > > > > Enclosed is a patch that allows me to specify the string to be > > substituted in the "#!" line at the beginning of scripts and a > > documentation fragment for the new option. > > > > Comments? > > Looks Ok. Please upload it to the SourceForge tracker. > > Thanks, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Software directly from the Source (#1, May 12 2003) > >>> Python/Zope Products & Consulting ... http://www.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > EuroPython 2003, Charleroi, Belgium: 43 days left From Anthony Baxter Tue May 13 07:23:02 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue May 13 06:23:02 2003 Subject: [Distutils] distutils reference documentation work in progress In-Reply-To: <200305121606.h4CG6j906961@localhost.localdomain> Message-ID: <200305131021.h4DALuc01531@localhost.localdomain> >>> Anthony Baxter wrote > > I've started on a complete reference for distutils and it's piles and > piles of goodies. It's very much a work in progress right now (I doubt > it's even completely valid LaTeX yet :) but there's a slab of it done > at http://www.interlink.com.au/anthony/tmp/distref_tex.txt Rather than keep working on a local file and screwing myself up, the documentation in progress is now checked into the python CVS, as nondist/sandbox/distutilref/ See ViewCVS at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/distutilsref/ Anthony From fdrake@acm.org Tue May 13 18:55:01 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue May 13 17:55:01 2003 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Doc/dist dist.tex,1.53,1.54 In-Reply-To: <200305131509.h4DF9Kg08030@localhost.localdomain> References: <200305131509.h4DF9Kg08030@localhost.localdomain> Message-ID: <16065.26977.138744.429944@grendel.zope.com> Anthony Baxter writes: > It's probably worth noting that the reference manual I'm writing > (see the sandbox) and the existing two Distutils docs need to > interact in some way. I'm not sure what that is yet, though... I see two possibilities, and have a fairly strong preference for one: 1. Include it in the "Distributing Python Modules" document. This makes a lot of sense, since the most common users of this documentation will be people trying to make distutils do the right thing for their package. This is also not unreasonable for people trying to extend distutils to support additional compilers, binary packages, and the like. 2. Distutils could have a chapter in the Library Reference. This isn't unreasonable, it just doesn't have anything else to recommend it. Clearly, I prefer option 1. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From krjackson@lbl.gov Tue May 13 19:21:27 2003 From: krjackson@lbl.gov (Keith Jackson) Date: Tue May 13 18:21:27 2003 Subject: [Distutils] compilation error (multiple compilations) In-Reply-To: <86E542AE-5A7A-11D7-B202-000A9577489A@lbl.gov> Message-ID: <13C20956-8591-11D7-B157-000A9577489A@lbl.gov> FYI, we finally figured this out sort of. The problem arises when a list containing only the empty string is passed into the extra_compile_args argument to Extension. This came up since we're getting some CFLAGS settings from the package we're wrapping. A simple check to ensure we have a real value for this solves the problem. I still have no clue why this happens though. Just thought I'd send out a response in case this bites anyone else. --keith On Wednesday, March 19, 2003, at 06:20 PM, Keith Jackson wrote: > Does anybody know why I'm getting the following error when compiling > an extension module with gcc and distutils? The compile line works > fine when I run it by hand, but when distutils runs it I get the > following error: > gcc: cannot specify -o with -c or -S and multiple compilations > error: command 'gcc' failed with exit status 1 > > Here's the line that causes the error: > gcc -DNDEBUG -O3 -I/sw/globus/globus/include/gcc32dbgpthr > -I/sw/include/python2.2 -c src/ftpControl_wrap.c -o > build/temp.darwin-6.4-PowerMacintosh-2.2/ftpControl_wrap.o > > Any thoughts? > thx, > --keith > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig From Anthony Baxter Wed May 14 00:53:02 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue May 13 23:53:02 2003 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Doc/dist dist.tex,1.53,1.54 In-Reply-To: <16065.26977.138744.429944@grendel.zope.com> Message-ID: <200305140351.h4E3puN16318@localhost.localdomain> >>> "Fred L. Drake, Jr." wrote > 1. Include it in the "Distributing Python Modules" document. This > makes a lot of sense, since the most common users of this > documentation will be people trying to make distutils do the > right thing for their package. This is also not unreasonable for > people trying to extend distutils to support additional > compilers, binary packages, and the like. The problem is (for me) distinguishing between "Installing" and "Distributing". I'm not sure why there's two separate documents. > 2. Distutils could have a chapter in the Library Reference. This > isn't unreasonable, it just doesn't have anything else to > recommend it. > > Clearly, I prefer option 1. ;-) There should probably be a bit more in the library ref about distutils - there's a bunch of useful material in the package, and it'd be a shame for people to re-invent the wheel again and again because they don't know it's there. For instance, the Compiler support could easily be used by some of the Python-based build tools. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From fdrake@acm.org Wed May 14 02:25:02 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed May 14 01:25:02 2003 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Doc/dist dist.tex,1.53,1.54 In-Reply-To: <200305140351.h4E3puN16318@localhost.localdomain> References: <16065.26977.138744.429944@grendel.zope.com> <200305140351.h4E3puN16318@localhost.localdomain> Message-ID: <16065.53983.321257.219173@grendel.zope.com> [I've removed python-checkins from the list of recipients.] Anthony Baxter writes: > The problem is (for me) distinguishing between "Installing" and > "Distributing". I'm not sure why there's two separate documents. Greg and I talked about these documents a fair bit when they were first being developed, so I think I'm fairly safe in describing our intentions of the time. "Installing" should be accessible without any knowledge of the Python language. This is for system administrators who need to know how software is installed and managed on their systems. "Distributing" is for people who write setup.py scripts or otherwise work with distutils from Python. This is very specifically for people more knowledgable regarding Python and the specific software packaged using the distutils. > There should probably be a bit more in the library ref about distutils - > there's a bunch of useful material in the package, and it'd be a shame > for people to re-invent the wheel again and again because they don't know > it's there. For instance, the Compiler support could easily be used by > some of the Python-based build tools. That's a possibility, and not without merit. Given the general difficulty people have in locating information about distutils, I'm not inclined to point to still more places. Would perhaps a somewhat more elaborate description in the distutils section of the library reference, with interesting index entries, be sufficient to drive people to the right places within the distutils-specific documents? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Anthony Baxter Wed May 14 04:29:01 2003 From: Anthony Baxter (Anthony Baxter) Date: Wed May 14 03:29:01 2003 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Doc/dist dist.tex,1.53,1.54 In-Reply-To: <16065.53983.321257.219173@grendel.zope.com> Message-ID: <200305140728.h4E7SVe19360@localhost.localdomain> >>> "Fred L. Drake, Jr." wrote > "Installing" should be accessible without any knowledge of the Python > language. This is for system administrators who need to know how > software is installed and managed on their systems. > > "Distributing" is for people who write setup.py scripts or otherwise > work with distutils from Python. This is very specifically for people > more knowledgable regarding Python and the specific software packaged > using the distutils. Ah, ok. That makes more sense. Ok, so most of the documentation goes into "Distributing". It may be that some ground that's covered in Installing also ends up (in a reduced form) in Distributing, with references to the appropriate place in the Installing documnent. > > There should probably be a bit more in the library ref about distutils - > > That's a possibility, and not without merit. Given the general > difficulty people have in locating information about distutils, I'm > not inclined to point to still more places. Would perhaps a somewhat > more elaborate description in the distutils section of the library > reference, with interesting index entries, be sufficient to drive > people to the right places within the distutils-specific documents? Yeah - I'd like there to at least be a basic description of the major chunks of distutils functionality (Compiler, Extension, Command, dependencies and the like) in the libref -- with pointers to the fuller reference materials in the Distributing doco... While having more places for documentation isn't a great thing, neither is having the docs in a separate document that's not obviously available. :) But for now, I'm working on just getting libref-like exhaustive documentation of all the modules, functions, methods and classes. Once that's done, massaging it into a couple of documents should be relatively painless (well, compared to the effort to document it all). Not sure if I'll get this done in time for 2.3... Hope to. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From anthony@interlink.com.au Wed May 14 04:32:01 2003 From: anthony@interlink.com.au (Anthony Baxter) Date: Wed May 14 03:32:01 2003 Subject: [Distutils] backwards compatibility of distutils? Message-ID: <200305140731.h4E7VJr19405@localhost.localdomain> When is it ok to lose the backward-compatibility of distutils? Going through the code, there's at least two entire modules (log and fancy_getopt) that should be removed in favour of the new logging and optparse modules. Obviously this isn't possible if 1.5.2 compatibility is to be kept. Or should they be replaced with copies of the logging and optparse modules in the distutils CVS tree? Anthony -- Anthony Baxter It's never too late to have a happy childhood. From mal@lemburg.com Wed May 14 04:48:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed May 14 03:48:02 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <200305140731.h4E7VJr19405@localhost.localdomain> References: <200305140731.h4E7VJr19405@localhost.localdomain> Message-ID: <3EC1F487.90406@lemburg.com> Anthony Baxter wrote: > When is it ok to lose the backward-compatibility of distutils? > Going through the code, there's at least two entire modules (log > and fancy_getopt) that should be removed in favour of the > new logging and optparse modules. Obviously this isn't possible > if 1.5.2 compatibility is to be kept. Last time we discussed this the conclusion was that 1.5.2 compatibility is needed for 2.3 and we can then move on to 2.0 compatibility for 2.4. > Or should they be replaced with copies of the logging and optparse > modules in the distutils CVS tree? Not for 2.3, but perhaps for 2.4 if those modules are 2.0 compatible. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 14 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 41 days left From jh@web.de Wed May 14 05:37:02 2003 From: jh@web.de (Juergen Hermann) Date: Wed May 14 04:37:02 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <200305140731.h4E7VJr19405@localhost.localdomain> Message-ID: On=20Wed,=2014=20May=202003=2017:31:19=20+1000,=20Anthony=20Baxter=20wrote= : >new=20logging=20and=20optparse=20modules.=20Obviously=20this=20isn't=20po= ssible=20 >if=201.5.2=20compatibility=20is=20to=20be=20kept. I=20don't=20care=20about=201.5.2,=20but=20about=202.2=20as=20the=20current= =20"stable"=20Python=20 platform. Ciao,=20J=FCrgen -- J=FCrgen=20Hermann,=20Developer WEB.DE=20AG,=20http://webde-ag.de/ From akuchlin@mems-exchange.org Wed May 14 11:10:00 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 10:10:00 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <200305140731.h4E7VJr19405@localhost.localdomain> References: <200305140731.h4E7VJr19405@localhost.localdomain> Message-ID: <20030514140904.GA21512@ute.mems-exchange.org> On Wed, May 14, 2003 at 05:31:19PM +1000, Anthony Baxter wrote: >When is it ok to lose the backward-compatibility of distutils? >Going through the code, there's at least two entire modules (log >and fancy_getopt) that should be removed in favour of the >new logging and optparse modules. Obviously this isn't possible >if 1.5.2 compatibility is to be kept. The unknown question is if anyone has written setup.py files that depend on fancy_getopt or distutils.log. It seems unlikely, but I don't know for sure, and breaking people's setup.py files is bad. This also makes me paranoid about rearranging command classes significantly. Perhaps if the PyPI catalog gets very complete, it can be used to take a survey of setup.py and find out how often people do something fancier than just calling setup(). >Or should they be replaced with copies of the logging and optparse >modules in the distutils CVS tree? Quite likely; the copies would only need to be in the CVS tree for the standalone Distutils distribution. --amk (www.amk.ca) "The solution." Oh, my little friend, if only you were... -- The Doctor, in "Castrovalva" From akuchlin@mems-exchange.org Wed May 14 11:14:02 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 10:14:02 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <3EC1F487.90406@lemburg.com> References: <200305140731.h4E7VJr19405@localhost.localdomain> <3EC1F487.90406@lemburg.com> Message-ID: <20030514141337.GB21512@ute.mems-exchange.org> On Wed, May 14, 2003 at 09:47:19AM +0200, M.-A. Lemburg wrote: >Last time we discussed this the conclusion was that 1.5.2 >compatibility is needed for 2.3 and we can then move >on to 2.0 compatibility for 2.4. Why 2.0- and not 2.2-compatible? 2.2 is the version the PBF is concentrating on; are 2.0/2.1 of much interest to customers? --amk From akuchlin@mems-exchange.org Wed May 14 11:17:01 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 10:17:01 2003 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Doc/dist dist.tex,1.53,1.54 In-Reply-To: <16065.53983.321257.219173@grendel.zope.com> References: <16065.26977.138744.429944@grendel.zope.com> <200305140351.h4E3puN16318@localhost.localdomain> <16065.53983.321257.219173@grendel.zope.com> Message-ID: <20030514141626.GC21512@ute.mems-exchange.org> On Wed, May 14, 2003 at 01:23:43AM -0400, Fred L. Drake, Jr. wrote: >"Installing" should be accessible without any knowledge of the Python >language. This is for system administrators who need to know how >software is installed and managed on their systems. "Installing" is also fairly close to complete, I think. The only remaining XXX comments in it are for MacOS-related things. "Distributing" is pretty incomplete, though. --amk From mal@lemburg.com Wed May 14 11:24:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed May 14 10:24:02 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <20030514141337.GB21512@ute.mems-exchange.org> References: <200305140731.h4E7VJr19405@localhost.localdomain> <3EC1F487.90406@lemburg.com> <20030514141337.GB21512@ute.mems-exchange.org> Message-ID: <3EC25121.4050905@lemburg.com> Andrew Kuchling wrote: > On Wed, May 14, 2003 at 09:47:19AM +0200, M.-A. Lemburg wrote: > >>Last time we discussed this the conclusion was that 1.5.2 >>compatibility is needed for 2.3 and we can then move >>on to 2.0 compatibility for 2.4. > > Why 2.0- and not 2.2-compatible? 2.2 is the version the PBF is > concentrating on; are 2.0/2.1 of much interest to customers? I'm not talking about customers or the PBF. If you're starting to go for Python 2.2 in distutils, then it'll become very hard for code publishers to provide Python 2.0/2.1 versions of their code and, yes, these version are still in use out there. Besides, I don't think that distutils really needs any of the features in versions later than Python 2.0. The only reason I see for moving to later version would be the integration or use of Python std lib modules from later Python versions. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 14 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 41 days left From akuchlin@mems-exchange.org Wed May 14 11:25:01 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 10:25:01 2003 Subject: [Distutils] compilation error (multiple compilations) In-Reply-To: <13C20956-8591-11D7-B157-000A9577489A@lbl.gov> References: <86E542AE-5A7A-11D7-B202-000A9577489A@lbl.gov> <13C20956-8591-11D7-B157-000A9577489A@lbl.gov> Message-ID: <20030514142451.GD21512@ute.mems-exchange.org> On Tue, May 13, 2003 at 03:20:17PM -0700, Keith Jackson wrote: >FYI, we finally figured this out sort of. The problem arises when a >list containing only the empty string is passed into the >extra_compile_args argument to Extension. This came up since we're At least on platforms that use unixccompiler.py, the contents of the extra_compile_args list ends up being passed to os.execvp(). An empty string therefore ends up looking like the shell invocation 'gcc --foo --bar --baz ""', and the zero-length string argument must mess things up. Protection against this might be added by dropping all empty strings from the list, but I don't think that's a good idea; if this was done, how would you supply an empty string when you really want to? --amk (www.amk.ca) "Mr. Holmes, they were the footprints of a gigantic hound!" -- Dr Mortimer, in "The Hound of the Baskervilles" From fredrik@pythonware.com Wed May 14 11:43:28 2003 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed May 14 10:43:28 2003 Subject: [Distutils] Re: backwards compatibility of distutils? References: <200305140731.h4E7VJr19405@localhost.localdomain> <3EC1F487.90406@lemburg.com> <20030514141337.GB21512@ute.mems-exchange.org> <3EC25121.4050905@lemburg.com> Message-ID: M.-A. Lemburg wrote: > If you're starting to go for Python 2.2 in distutils, then > it'll become very hard for code publishers to provide Python > 2.0/2.1 versions of their code and, yes, these version are > still in use out there. fwiw, 2.1 accounts for about 20% of the PIL 1.1.4 downloads. From akuchlin@mems-exchange.org Wed May 14 12:02:01 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 11:02:01 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <3EC25121.4050905@lemburg.com> References: <200305140731.h4E7VJr19405@localhost.localdomain> <3EC1F487.90406@lemburg.com> <20030514141337.GB21512@ute.mems-exchange.org> <3EC25121.4050905@lemburg.com> Message-ID: <20030514150138.GA21618@ute.mems-exchange.org> On Wed, May 14, 2003 at 04:22:25PM +0200, M.-A. Lemburg wrote: >If you're starting to go for Python 2.2 in distutils, then >it'll become very hard for code publishers to provide Python >2.0/2.1 versions of their code and, yes, these version are >still in use out there. I don't follow this. Publishers write a setup.py against the Distutils API; this has to run on the Python version being used. In implementing the API, the Distutils code can use 2.2 or not, but that's irrelevant to publishers as long as the installed version of Distutils actually runs. >features in versions later than Python 2.0. The only reason >I see for moving to later version would be the integration >or use of Python std lib modules from later Python versions. ... which is in fact what Anthony was wondering about. Both logging and optparse/Optik seem to be supported under 2.0/2.1, so including a copy shouldn't need any backporting; the requisite sys.path manipulations might be a bit of a pain, though. As long as we avoid generators, everything should be fine. --amk (www.amk.ca) HAMLET: There's a special providence in the fall of a sparrow. -- _Hamlet_, V, ii From Paul.Moore@atosorigin.com Wed May 14 12:46:01 2003 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed May 14 11:46:01 2003 Subject: [Distutils] backwards compatibility of distutils? Message-ID: <16E1010E4581B049ABC51D4975CEDB88619A75@UKDCX001.uk.int.atosorigin.com> From: Andrew Kuchling [mailto:akuchlin@mems-exchange.org] > On Wed, May 14, 2003 at 04:22:25PM +0200, M.-A. Lemburg wrote: > > >If you're starting to go for Python 2.2 in distutils, then it'll > >become very hard for code publishers to provide Python 2.0/2.1 > >versions of their code and, yes, these version are still in use out > >there. > > I don't follow this. Publishers write a setup.py against the > Distutils API; this has to run on the Python version being used. In > implementing the API, the Distutils code can use 2.2 or not, but > that's irrelevant to publishers as long as the installed version of > Distutils actually runs. I think the issue is that the "distutils API" isn't entirely well- defined. My usage of the distutils API is entirely trivial, and I don't expect I'd have any problem with the version packaged with Python x.y using features in Python x.y. I'd just use the appropriate Python/distutils versions and run python setup.py bdist_wininst N times. Done. But people writing fancy setup.py code subclass Distutils classes, use "internal" utility modules (the fancy_getopt module comes to mind here), and who knows what else. These people (MAL is definitely one of them) have to worry a lot about setup.py compatibility with different distutils versions. This message would be more useful if I knew what the solution to the problem was :-) [I have a suspicion that it's "document the official API, and use the time machine", but I don't have the keys to the time machine...] Paul. From akuchlin@mems-exchange.org Wed May 14 14:30:03 2003 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed May 14 13:30:03 2003 Subject: [Distutils] Current draft of PEP 314 Message-ID: [Crossposted to Distutils-SIG and Catalog-SIG; followups set to Distutils-SIG.] Here's the current draft of PEP 314, which updates the format of the PKG-INFO file originally specified in PEP 241. From the section "Summary of Differences From PEP 241": * Metadata-Version is now 1.1. * Added the Classifiers field from PEP 301. * Added fields: Download-URL, Requires, Provides, Obsoletes, Conflicts. The remaining open issue is whether to deprecate the 'license' and 'platform' keyword arguments to setup(), on the grounds that the 'classifiers' list contains entries for this, and there should be only one way to do it. Comments welcome. --amk (www.amk.ca) Dream? Give me your hand. -- Death, in SANDMAN #69: "The Kindly Ones:13" PEP: 314 Title: Metadata for Python Software Packages v1.1 Version: $Revision: 1.15 $ Last-Modified: $Date: 2003/05/14 17:12:55 $ Author: A.M. Kuchling Status: Draft Type: Standards Track Content-type: text/plain Created: 12-Apr-2003 Python-Version: 2.3 Post-History: 29-Apr-2003 Replaces: 241 Introduction This PEP describes a mechanism for adding metadata to Python packages. It includes specifics of the field names, and their semantics and usage. This document specifies version 1.1 of the metadata format. Version 1.0 is specified in PEP 241. Including Metadata in Packages The Distutils 'sdist' command will extract the metadata fields from the arguments and write them to a file in the generated zipfile or tarball. This file will be named PKG-INFO and will be placed in the top directory of the source distribution (where the README, INSTALL, and other files usually go). Developers may not provide their own PKG-INFO file. The "sdist" command will, if it detects an existing PKG-INFO file, terminate with an appropriate error message. This should prevent confusion caused by the PKG-INFO and setup.py files being out of sync. The PKG-INFO file format is a single set of RFC-822 headers parseable by the rfc822.py module. The field names listed in the following section are used as the header names. Fields This section specifies the names and semantics of each of the supported metadata fields. Fields marked with "(Multiple use)" may be specified multiple times in a single PKG-INFO file. Other fields may only occur once in a PKG-INFO file. Fields marked with "(optional)" are not required to appear in a valid PKG-INFO file; all other fields must be present. Metadata-Version Version of the file format; currently "1.0" and "1.1" are the only legal values here. Example: Metadata-Version: 1.1 Name The name of the package. Example: Name: BeagleVote Version A string containing the package's version number. This field should be parseable by one of the Version classes (StrictVersion or LooseVersion) in the distutils.version module. Example: Version: 1.0a2 Platform (multiple use) A comma-separated list of platform specifications, summarizing the operating systems supported by the package. The major supported platforms are listed below, but this list is necessarily incomplete. POSIX, MacOS, Windows, BeOS, PalmOS. Example: Platform: POSIX, Windows Supported-Platform (multiple use) Binary distributions containing a PKG-INFO file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary package was compiled. The semantics of the Supported-Platform field are not specified in this PEP. Example: Supported-Platform: RedHat 7.2 Supported-Platform: i386-win32-2791 Summary A one-line summary of what the package does. Example: Summary: A module for collecting votes from beagles. Description (optional) A longer description of the package that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field, though people shouldn't include their instruction manual as the description. The contents of this field can be written using reStructuredText markup [1]. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use. Example: Description: This module collects votes from beagles in order to determine their electoral wishes. Do *not* try to use this module with basset hounds; it makes them grumpy. Keywords (optional) A list of additional keywords to be used to assist searching for the package in a larger catalog. Example: Keywords: dog puppy voting election Home-page (optional) A string containing the URL for the package's home page. Example: Home-page: http://www.example.com/~cschultz/bvote/ Download-URL A string containing the URL from which this version of the package can be downloaded. (This means that the URL can't be something like ".../package-latest.tgz", but instead must be "../package-0.45.tgz".) Author (optional) A string containing the author's name at a minimum; additional contact information may be provided. Example: Author: C. Schultz, Universal Features Syndicate, Los Angeles, CA Author-email A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 'From:' header. It's not optional because cataloging systems can use the e-mail portion of this field as a unique key representing the author. A catalog might provide authors the ability to store their GPG key, personal home page, and other additional metadata *about the author*, and optionally the ability to associate several e-mail addresses with the same person. Author-related metadata fields are not covered by this PEP. Example: Author-email: "C. Schultz" License A string selected from a short list of choices, specifying the license covering the package. Some licenses result in the software being freely redistributable, so packagers and resellers can automatically know that they're free to redistribute the software. Other licenses will require a careful reading by a human to determine how the software can be repackaged and resold. The choices are: Artistic, BSD, DFSG, GNU GPL, GNU LGPL, "MIT", Mozilla PL, "public domain", Python, Qt PL, Zope PL, unknown, nocommercial, nosell, nosource, shareware, other Definitions of some of the licenses are: DFSG The license conforms to the Debian Free Software Guidelines, but does not use one of the other DFSG conforming licenses listed here. More information is available at: http://www.debian.org/social_contract#guidelines Python Python 1.6 or higher license. Version 1.5.2 and earlier are under the MIT license. public domain Software is public domain, not copyrighted. unknown Status is not known nocommercial Free private use but commercial use not permitted nosell Free use but distribution for profit by arrangement nosource Freely distributable but no source code shareware Payment is requested if software is used other General category for other non-DFSG licenses Some of these licenses can be interpreted to mean the software is freely redistributable. The list of redistributable licenses is: Artistic, BSD, DFSG, GNU GPL, GNU LGPL, "MIT", Mozilla PL, "public domain", Python, Qt PL, Zope PL, nosource, shareware Note that being redistributable does not mean a package qualifies as free software, 'nosource' and 'shareware' being examples. Example: License: MIT Classifier (multiple use) Each entry is a string giving a single classification value for the package. Classifiers are described in PEP 301 [2]. Examples: Classifier: Development Status :: 4 - Beta Classifier: Environment :: Console (Text Based) Requires (multiple use) Each entry contains a string describing some other component or module required by this package. The format of a requirement string is simple: an arbitrary sequence of characters, optionally followed by a version declaration within parentheses. Leading and trailing whitespace are ignored, and whitespace within the string is normalized to a single space. A version declaration is a series of conditional operators and version numbers, separated by commas. Conditional operators must be one of "<", ">", "<=", ">=", "==", and "!=". Version numbers must be in the format accepted by the distutils.version.StrictVersion class: two or three dot-separated numeric components, with an optional "pre-release" tag on the end consisting of the letter 'a' or 'b' followed by a number. Example version numbers are "1.0", "2.3a2", "1.3.99", Any number of conditional operators can be specified, e.g. the string ">1.0, !=1.3.4, <2.0" is a legal version declaration. All of the following are possible requirement strings: "rfc822", "zlib (>=1.1.4)", "XML parser". There's no canonical list of what strings should be used; the Python community is left to choose its own standards. Example: Requires: re Requires: sys Requires: zlib Requires: pyexpat (>1.0) Requires: DB-API 2.0 module Provides (multiple use) Each entry contains a string describing a component or module that will be provided by this package once it is installed. These strings should match the ones used in Requirements fields. Version declarations cannot be supplied; instead the package's version number will be used. Example: Provides: xml Provides: xml.utils Provides: xml.utils.iso8601 Provides: xml.dom Obsoletes (multiple use) Each entry contains a string describing a component or module that this package renders obsolete, meaning that the two packages should not be installed at the same time. Version declarations can be supplied. The most common use of this field will be in case a package name changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install Torqued Python, the Gorgon package should be removed. Example: Obsoletes: Gorgon Conflicts (multiple use) Each entry contains a string describing a component or module that conflicts with this package, meaning that the two packages should not be installed at the same time. Version declarations can be supplied. Conflict resolution probably isn't very important for Python programs, because few extensions will cause problems for other extensions, unless they happen to be using the same package name. This field name is being defined here for future use. Conflicts: Gorgon Summary of Differences From PEP 241 * Metadata-Version is now 1.1. * Added the Classifiers field from PEP 301. * Added fields: Download-URL, Requires, Provides, Obsoletes, Conflicts. Open issues With the addition of the 'Classifiers' field, should the Platform and License fields be removed? Acknowledgements Richard Jones suggested using reST for the Description field. References [1] reStructuredText http://docutils.sourceforge.net/ [2] PEP 301 http://www.python.org/peps/pep-0301.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From Anthony Baxter Wed May 14 22:28:01 2003 From: Anthony Baxter (Anthony Baxter) Date: Wed May 14 21:28:01 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <20030514140904.GA21512@ute.mems-exchange.org> Message-ID: <200305150126.h4F1QhK28052@localhost.localdomain> >>> Andrew Kuchling wrote > The unknown question is if anyone has written setup.py files that > depend on fancy_getopt or distutils.log. It seems unlikely, but I > don't know for sure, and breaking people's setup.py files is bad. > This also makes me paranoid about rearranging command classes > significantly. We could ask on comp.lang.python... I'll do this. "Do you know of setup.py files that are more complex than just a setup call with some usage of Extension?" I know Richard Jones has a reasonably complex setup.py for roundup; it monkeypatches DistributionMetadata and does a bunch of work to build the install list. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From Alexandre.Fayolle@logilab.fr Thu May 15 03:37:01 2003 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Thu May 15 02:37:01 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <200305150126.h4F1QhK28052@localhost.localdomain> References: <20030514140904.GA21512@ute.mems-exchange.org> <200305150126.h4F1QhK28052@localhost.localdomain> Message-ID: <20030515063632.GE9099@calvin> On Thu, May 15, 2003 at 11:26:42AM +1000, Anthony Baxter wrote: > > >>> Andrew Kuchling wrote > > The unknown question is if anyone has written setup.py files that > > depend on fancy_getopt or distutils.log. It seems unlikely, but I > > don't know for sure, and breaking people's setup.py files is bad. > > This also makes me paranoid about rearranging command classes > > significantly. > > We could ask on comp.lang.python... I'll do this. > > "Do you know of setup.py files that are more complex than just > a setup call with some usage of Extension?" > > I know Richard Jones has a reasonably complex setup.py for roundup; > it monkeypatches DistributionMetadata and does a bunch of work to > build the install list. PyXML's setup.py does some additional command line argument processing, to check if some parts of the library should be installed or not. There's also some work for Expat handling, and some workarounds for Distutils 1.0 bugs on Windows. Some additional commands are also provided (install_data for gettext data files), and there are some extensions for bdist_wininst. http://pyxml.sf.net/ Fourthought has a huge extension of Distutils called PackageManager (more than 3500 lines of code). I don't know how deeply it relies on the core distutils. http://www.4suite.org/ -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations From robin@jessikat.fsnet.co.uk Thu May 15 15:48:01 2003 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Thu May 15 14:48:01 2003 Subject: [Distutils] Mac OS 9 Message-ID: anyone had any success with distutils on MAc OS 9? I'm using macpython 2.2.2 with code warrior 8.02 and am not getting past the mcp build stage. Also I'm getting a locked machine after the failure for some reason. Is it just me or have others seen problems? -- Robin Becker From L-marks@northwestern.edu Thu May 15 20:23:17 2003 From: L-marks@northwestern.edu (L D Marks) Date: Thu May 15 19:23:17 2003 Subject: [Distutils] distutils failing to read python Makefile information Message-ID: <000001c31b38$ce9e1150$0600000a@numis.nwu.edu> I have a bug (?): distutils does not seem to be reading information from the python Makefile, and is instead using a very basic "cc" compiler with few options. This won't work since the cc compiler on the machine I am using is not great. Any suggestions of where to start? Background information: I'm using gcc 3.1 on an HPUX 10.20 computer. The version of python I used was 2.2.1. Python appears to be OK (I'm not an expert) and I only noticed the problem when I tried to compile PyOpenGL (which I need for some other software). I'm not sure if this is relevant, but python is also not picking up any information from PATH or other variables (e.g. CC). -------------------------------------------- Laurence Marks Department of Materials Science and Engineering Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.northwestern.edu http://www.numis.northwestern.edu -------------------------------------------- From mal@lemburg.com Fri May 16 10:00:03 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri May 16 09:00:03 2003 Subject: [Distutils] backwards compatibility of distutils? In-Reply-To: <20030514150138.GA21618@ute.mems-exchange.org> References: <200305140731.h4E7VJr19405@localhost.localdomain> <3EC1F487.90406@lemburg.com> <20030514141337.GB21512@ute.mems-exchange.org> <3EC25121.4050905@lemburg.com> <20030514150138.GA21618@ute.mems-exchange.org> Message-ID: <3EC4E047.6060503@lemburg.com> Andrew Kuchling wrote: > On Wed, May 14, 2003 at 04:22:25PM +0200, M.-A. Lemburg wrote: > >>If you're starting to go for Python 2.2 in distutils, then >>it'll become very hard for code publishers to provide Python >>2.0/2.1 versions of their code and, yes, these version are >>still in use out there. > > I don't follow this. Publishers write a setup.py against the > Distutils API; this has to run on the Python version being used. In > implementing the API, the Distutils code can use 2.2 or not, but > that's irrelevant to publishers as long as the installed version of > Distutils actually runs. Ok, let's make this clearer: it is indeed irrelevant if you're just using very simple setup.py files together with your code. These are likely to work with all distutils currently in use out there... But if you start extending distutils in various ways to better meet your requirements, then you're stuck, since you will either have to build different versions for different distutils version, add lots of if-elif-else conditional tricks or simply give up and not support older versions anymore. The problem (and at the same its strength) in distutil's design is that it is a system which provides a framework. This makes replacing parts in distutils rather hard because that would likely break existing setup.py configurations out there. >>features in versions later than Python 2.0. The only reason >>I see for moving to later version would be the integration >>or use of Python std lib modules from later Python versions. > > ... which is in fact what Anthony was wondering about. Both logging > and optparse/Optik seem to be supported under 2.0/2.1, so including a > copy shouldn't need any backporting; the requisite sys.path > manipulations might be a bit of a pain, though. As long as we avoid > generators, everything should be fine. The question really is: do you want to force people using older Python versions to upgrade their distutils version before installing a package or not. Given that the current distutils is so easy to use, I think that would raise the bar considerably for the casual user... unless you ship a complete copy of distutils together with your source package which is how MS does it :-/ -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 16 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 39 days left From harri.pasanen@trema.com Mon May 19 13:36:01 2003 From: harri.pasanen@trema.com (Harri Pasanen) Date: Mon May 19 12:36:01 2003 Subject: [Distutils] Patch for unixccompiler.py to support HP-UX + gcc Message-ID: <200305191835.10492.harri.pasanen@trema.com> Hello, gcc on hp-ux uses the native linker, so if gcc is used there, the normal gcc flags do not apply. I propose the following patch to unixccompiler.py ----8<------------8<-----------------8<------------8<-----------------8<------- 206,207c206,209 < elif compiler[:3] == "gcc" or compiler[:3] == "g++": < return "-Wl,-R" + dir --- > elif sys.platform[:5] == "hp-ux": > return "+s -L" + dir > elif compiler[:3] == "gcc" or compiler[:3] == "g++": > return "-Wl,-R" + dir ----8<------------8<-----------------8<------------8<-----------------8<------- That also adds +s, which means that SHLIB_PATH is honored (the same as LD_LIBRARY_PATH on Linux/Solaris). Regards, Harri From mal@lemburg.com Mon May 19 13:45:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon May 19 12:45:02 2003 Subject: [Distutils] Patch for unixccompiler.py to support HP-UX + gcc In-Reply-To: <200305191835.10492.harri.pasanen@trema.com> References: <200305191835.10492.harri.pasanen@trema.com> Message-ID: <3EC909D4.5090603@lemburg.com> Harri Pasanen wrote: > Hello, > > gcc on hp-ux uses the native linker, so if gcc is used there, the > normal gcc flags do not apply. > > I propose the following patch to unixccompiler.py Please upload patches to SourceForge. That way, they don't get lost. Thanks. > ----8<------------8<-----------------8<------------8<-----------------8<------- > 206,207c206,209 > < elif compiler[:3] == "gcc" or compiler[:3] == "g++": > < return "-Wl,-R" + dir > --- > >> elif sys.platform[:5] == "hp-ux": >> return "+s -L" + dir >> elif compiler[:3] == "gcc" or compiler[:3] == "g++": >> return "-Wl,-R" + dir > > ----8<------------8<-----------------8<------------8<-----------------8<------- > > > That also adds +s, which means that SHLIB_PATH is honored (the same as > LD_LIBRARY_PATH on Linux/Solaris). > > Regards, > > Harri > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 19 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 36 days left From harri.pasanen@trema.com Tue May 20 05:00:02 2003 From: harri.pasanen@trema.com (Harri Pasanen) Date: Tue May 20 04:00:02 2003 Subject: [Distutils] Patch for unixccompiler.py to support HP-UX + gcc In-Reply-To: <3EC909D4.5090603@lemburg.com> References: <200305191835.10492.harri.pasanen@trema.com> <3EC909D4.5090603@lemburg.com> Message-ID: <200305200958.55312.harri.pasanen@trema.com> On Monday 19 May 2003 18:44, M.-A. Lemburg wrote: > > Please upload patches to SourceForge. That way, they don't get > lost. Thanks. Ok, done. -Harri From Jack.Jansen@cwi.nl Tue May 20 09:41:01 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue May 20 08:41:01 2003 Subject: [Distutils] Mac OS 9 In-Reply-To: Message-ID: <76B81E12-8AC0-11D7-805D-0030655234CE@cwi.nl> On Thursday, May 15, 2003, at 20:46 Europe/Amsterdam, Robin Becker wrote: > anyone had any success with distutils on MAc OS 9? I'm using macpython > 2.2.2 with code warrior 8.02 and am not getting past the mcp build > stage. There could be bugs in the support for CodeWarrior 8, as MacPython is built with CodeWarrior 7 and the project templates that distutils uses (through the mkcwproject package, look in :Mac:Lib:mwcwproject) are also for CW7. What do you mean by "not getting past the build stage"? Do you get errors, or do things simply stop? And when the machine locks up, can you get it going again with command-.? There is a problem with distutils when running MacPython 2.2.2 on OSX: it can't find one of its include directories. Thre's an SF bug report filed for this (740424). -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From robin@jessikat.fsnet.co.uk Tue May 20 12:24:20 2003 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue May 20 11:24:20 2003 Subject: [Distutils] Mac OS 9 In-Reply-To: <76B81E12-8AC0-11D7-805D-0030655234CE@cwi.nl> References: <76B81E12-8AC0-11D7-805D-0030655234CE@cwi.nl> Message-ID: In article <76B81E12-8AC0-11D7-805D-0030655234CE@cwi.nl>, Jack Jansen writes > >On Thursday, May 15, 2003, at 20:46 Europe/Amsterdam, Robin Becker >wrote: > >> anyone had any success with distutils on MAc OS 9? I'm using macpython >> 2.2.2 with code warrior 8.02 and am not getting past the mcp build >> stage. > >There could be bugs in the support for CodeWarrior 8, as MacPython is >built with CodeWarrior 7 and the project templates that distutils uses >(through the mkcwproject package, look in :Mac:Lib:mwcwproject) are >also for CW7. > >What do you mean by "not getting past the build stage"? Do you get >errors, or do things simply stop? And when the machine locks up, can >you get it going again with command-.? > In Mac OS 9 at least once the machine locked and the python instances was unkillable. Interestingly after the reboot we tried again and although the build didn't continue we at least got a built .mcp which was where the distutils build broke down. >There is a problem with distutils when running MacPython 2.2.2 on OSX: >it can't find one of its include directories. Thre's an SF bug report >filed for this (740424). we're just trying out OS X now. Someone tells me I can use GCC derived tools and expertise :) >-- >Jack Jansen, , http://www.cwi.nl/~jack >If I can't dance I don't want to be part of your revolution -- Emma >Goldman > > -- Robin Becker From Jack.Jansen@cwi.nl Tue May 20 18:24:03 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue May 20 17:24:03 2003 Subject: [Distutils] Mac OS 9 In-Reply-To: Message-ID: <43A73C14-8B09-11D7-AC6D-000A27B19B96@cwi.nl> On dinsdag, mei 20, 2003, at 17:20 Europe/Amsterdam, Robin Becker wrote: >> What do you mean by "not getting past the build stage"? Do you get >> errors, or do things simply stop? And when the machine locks up, can >> you get it going again with command-.? >> > In Mac OS 9 at least once the machine locked and the python instances > was unkillable. Interestingly after the reboot we tried again and > although the build didn't continue we at least got a built .mcp which > was where the distutils build broke down. Hmm, interesting, I've never seen this. But the bad news is that I really have no idea how to go about debugging this... > >> There is a problem with distutils when running MacPython 2.2.2 on OSX: >> it can't find one of its include directories. Thre's an SF bug report >> filed for this (740424). > > we're just trying out OS X now. Someone tells me I can use GCC derived > tools and expertise :) If you use a unix-based Python (which means Apple-installed /usr/bin/python 2.2, or MacPython-2.3, or any python you built from source yourself) then you are indeed talking standard Unix stuff and there's no problem. If you for some reason need to use MacPython 2.2.X or MacPython-OS9 2.3 then you need CodeWarrior and you will run into bug 740424. But I'm trying to fix it before 2.2.3 comes out. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From gward at python.net Tue May 27 21:28:48 2003 From: gward at python.net (Greg Ward) Date: Tue May 27 20:28:51 2003 Subject: [Distutils] Re: FW: weird problem with startup In-Reply-To: <001501c32461$14fa9520$6501a8c0@NICKLEBY> References: <001501c32461$14fa9520$6501a8c0@NICKLEBY> Message-ID: <20030528002848.GB17625@cthulhu.gerg.ca> [BTW: distutils questions belong on distutils-sig@python.org] On 27 May 2003, Paul Dubois said: > However if one of my users has a path with a different Python in it before > the one I specify, on some platforms (AIX and tru64 (decs) in particular) > the end result is that "their" Python is run on my script. That sounds like a platform oddity in handling the #! line. If some Unix kernel doesn't handle #! lines in the standard way, there's not much the distutils can do. > If I put #!/usr/bin/env /path/to/python in my script, it works, but on some > but not all platforms distutils replaces that line with the /path/to/python > one and then it fails. Yeah, the code that munges the #! line -- specifically, the regex that looks for a "#!.*python" line -- has changed a bit over time. The result is that you should *not* use "#!/usr/bin/env python" in scripts that are to be distributed and installed by the distutils, even if it happens to work with your particular version of Python. Greg -- Greg Ward http://www.gerg.ca/ One man's theology is another man's belly laugh.