From webmaster at smallco.com Tue Jan 4 17:38:25 2005 From: webmaster at smallco.com (Webmaster) Date: Tue Jan 4 17:38:31 2005 Subject: [Distutils] Automatic response to your mail (Error) Message-ID: The automatic reply to this e-mail which you should have received in response to your e-mail to webmaster@smallco.com has not been defined. Please contact postmaster@smallco.com for assistance. From seefeld at sympatico.ca Wed Jan 5 22:24:01 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Jan 5 22:25:03 2005 Subject: [Distutils] distutils version numbering Message-ID: <41DC5AF1.6060001@sympatico.ca> hi there, I'm writing a custom 'build_scripts' command that works around a bug in earlier versions of distutils, i.e. it makes scripts executable on posix platforms after they got copied to the build_dir. I'm looking for a discriminator that allows me to decide whether or not to run the code, depending on whether the distutils version requires it. It seems the version coming with python 2.2 requires it, while python 2.3 and up don't. However, distutils.__version__ for python 2.2 as well as python 2.3 are the same ('1.0.3') ! Am I just looking in the wrong place ? Thanks, Stefan From mal at egenix.com Wed Jan 5 22:47:32 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 5 22:47:35 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DC5AF1.6060001@sympatico.ca> References: <41DC5AF1.6060001@sympatico.ca> Message-ID: <41DC6074.2090204@egenix.com> Stefan Seefeld wrote: > hi there, > > I'm writing a custom 'build_scripts' command > that works around a bug in earlier versions > of distutils, i.e. it makes scripts executable > on posix platforms after they got copied to > the build_dir. > > I'm looking for a discriminator that allows > me to decide whether or not to run the code, > depending on whether the distutils version > requires it. > > It seems the version coming with python 2.2 > requires it, while python 2.3 and up don't. > However, distutils.__version__ for python 2.2 > as well as python 2.3 are the same ('1.0.3') ! > > Am I just looking in the wrong place ? No, there was no distutils release after 1.0.3. Starting with Python 2.4, distutils seem to follow the Python version number (even though I'm not really sure who made that decision and what the motivation was). You should probably switch on both the distutils and Python version (it was and still is possible to install the current distutils package for Python 2.1). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 05 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From seefeld at sympatico.ca Wed Jan 5 22:54:33 2005 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Jan 5 22:55:34 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DC6074.2090204@egenix.com> References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> Message-ID: <41DC6219.501@sympatico.ca> M.-A. Lemburg wrote: > No, there was no distutils release after 1.0.3. but the version shipping with python 2.3 has API changes, so how can I figure out what version I'm using ? > Starting with Python 2.4, distutils seem to follow > the Python version number (even though I'm not really > sure who made that decision and what the motivation > was). > > You should probably switch on both the distutils > and Python version (it was and still is possible > to install the current distutils package for > Python 2.1). Ok, let me rephrase: script permissions are fixed if either I'm running python 2.3 or above, or distutils' own version is 2.4 or above. Correct ? Thanks, Stefan From mal at egenix.com Wed Jan 5 23:02:35 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 5 23:02:37 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DC6219.501@sympatico.ca> References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> <41DC6219.501@sympatico.ca> Message-ID: <41DC63FB.2030807@egenix.com> Stefan Seefeld wrote: > M.-A. Lemburg wrote: > > > No, there was no distutils release after 1.0.3. > > but the version shipping with python 2.3 has API changes, > so how can I figure out what version I'm using ? Introspection. Not exactly elegant, I know. > > Starting with Python 2.4, distutils seem to follow > > the Python version number (even though I'm not really > > sure who made that decision and what the motivation > > was). > > > > You should probably switch on both the distutils > > and Python version (it was and still is possible > > to install the current distutils package for > > Python 2.1). > > Ok, let me rephrase: script permissions are fixed > if either I'm running python 2.3 or above, or > distutils' own version is 2.4 or above. Correct ? Sounds about right. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 05 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Jan 6 09:59:55 2005 From: theller at python.net (Thomas Heller) Date: Thu Jan 6 09:58:36 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DC6074.2090204@egenix.com> (M.'s message of "Wed, 05 Jan 2005 22:47:32 +0100") References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> Message-ID: "M.-A. Lemburg" writes: > Stefan Seefeld wrote: >> hi there, >> I'm writing a custom 'build_scripts' command >> that works around a bug in earlier versions >> of distutils, i.e. it makes scripts executable >> on posix platforms after they got copied to >> the build_dir. >> I'm looking for a discriminator that allows >> me to decide whether or not to run the code, >> depending on whether the distutils version >> requires it. >> It seems the version coming with python 2.2 >> requires it, while python 2.3 and up don't. >> However, distutils.__version__ for python 2.2 >> as well as python 2.3 are the same ('1.0.3') ! >> Am I just looking in the wrong place ? > > No, there was no distutils release after 1.0.3. > Starting with Python 2.4, distutils seem to follow > the Python version number (even though I'm not really > sure who made that decision and what the motivation > was). That was me, and it seemed a sensible thing to do. And not changing the distutils version number in Python 2.3 was a mistake, imo. Thomas From mal at egenix.com Thu Jan 6 11:08:30 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 6 11:08:32 2005 Subject: [Distutils] distutils version numbering In-Reply-To: References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> Message-ID: <41DD0E1E.3090106@egenix.com> Thomas Heller wrote: > "M.-A. Lemburg" writes: > > >>Stefan Seefeld wrote: >> >>>hi there, >>>I'm writing a custom 'build_scripts' command >>>that works around a bug in earlier versions >>>of distutils, i.e. it makes scripts executable >>>on posix platforms after they got copied to >>>the build_dir. >>>I'm looking for a discriminator that allows >>>me to decide whether or not to run the code, >>>depending on whether the distutils version >>>requires it. >>>It seems the version coming with python 2.2 >>>requires it, while python 2.3 and up don't. >>>However, distutils.__version__ for python 2.2 >>>as well as python 2.3 are the same ('1.0.3') ! >>>Am I just looking in the wrong place ? >> >>No, there was no distutils release after 1.0.3. >>Starting with Python 2.4, distutils seem to follow >>the Python version number (even though I'm not really >>sure who made that decision and what the motivation >>was). > > > That was me, and it seemed a sensible thing to do. And not changing the > distutils version number in Python 2.3 was a mistake, imo. Indeed. The version number should change with each new release being made available - whether as stand-alone version or as part of a Python release. I'm not sure whether using the Python version number is correct, though. distutils is not developed at the same pace as Python and a step from Python 2.3 to 2.4 is not necessarily a major step in distutils development. On the other hand, not bumping the version number for API changes is bad as well. I think we ought to keep things separate to make development easier: if you make an API change in distutils, bump the version number. That's a lot easier than remembering to adjust the version string for each Python release. What do you think ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Jan 6 13:33:07 2005 From: theller at python.net (Thomas Heller) Date: Thu Jan 6 13:31:47 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DD0E1E.3090106@egenix.com> (M.'s message of "Thu, 06 Jan 2005 11:08:30 +0100") References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> <41DD0E1E.3090106@egenix.com> Message-ID: >>>>However, distutils.__version__ for python 2.2 >>>>as well as python 2.3 are the same ('1.0.3') ! >>>>Am I just looking in the wrong place ? >>> >>>No, there was no distutils release after 1.0.3. >>>Starting with Python 2.4, distutils seem to follow >>>the Python version number (even though I'm not really >>>sure who made that decision and what the motivation >>>was). >> That was me, and it seemed a sensible thing to do. And not changing >> the distutils version number in Python 2.3 was a mistake, imo. > > Indeed. The version number should change with each new release > being made available - whether as stand-alone version or > as part of a Python release. > > I'm not sure whether using the Python version number is > correct, though. distutils is not developed at the same > pace as Python and a step from Python 2.3 to 2.4 is not > necessarily a major step in distutils development. > > On the other hand, not bumping the version number > for API changes is bad as well. > > I think we ought to keep things separate to make development > easier: if you make an API change in distutils, bump the > version number. That's a lot easier than remembering to > adjust the version string for each Python release. > > What do you think ? For me, the exact value of the version number is pretty meaningless, even more if distutils is not developed separately from Python. So, 2.4 means 'the distutils included with Python 2.4'. Easier to remember that distutils 1.0.4 was the version released with 2.4. If it makes sense, I can take the resposibility to increase the version number with each release, and update the corresponding PEPs, but I won't object to the 'change API, bump version number' scheme as well. Thomas From mal at egenix.com Thu Jan 6 14:19:26 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 6 14:19:29 2005 Subject: [Distutils] distutils version numbering In-Reply-To: References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> <41DD0E1E.3090106@egenix.com> Message-ID: <41DD3ADE.8000901@egenix.com> Thomas Heller wrote: >>>>>However, distutils.__version__ for python 2.2 >>>>>as well as python 2.3 are the same ('1.0.3') ! >>>>>Am I just looking in the wrong place ? >>>> >>>>No, there was no distutils release after 1.0.3. >>>>Starting with Python 2.4, distutils seem to follow >>>>the Python version number (even though I'm not really >>>>sure who made that decision and what the motivation >>>>was). > > >>>That was me, and it seemed a sensible thing to do. And not changing >>>the distutils version number in Python 2.3 was a mistake, imo. >> >>Indeed. The version number should change with each new release >>being made available - whether as stand-alone version or >>as part of a Python release. >> >>I'm not sure whether using the Python version number is >>correct, though. distutils is not developed at the same >>pace as Python and a step from Python 2.3 to 2.4 is not >>necessarily a major step in distutils development. >> >>On the other hand, not bumping the version number >>for API changes is bad as well. >> >>I think we ought to keep things separate to make development >>easier: if you make an API change in distutils, bump the >>version number. That's a lot easier than remembering to >>adjust the version string for each Python release. >> >>What do you think ? > > For me, the exact value of the version number is pretty meaningless, > even more if distutils is not developed separately from Python. I have to disagree here: distutils *is* developed independent from the Python core, e.g. we keep Python 2.1 compatibility where Python core always tries to use the latest and greatest new feature of the language in the standard lib (not necessarily making things better, IMHO, but that's a different issue). The fact that we haven't had any stand-alone releases for quite a while does not mean that distutils is bound to the Python release cycle. > So, 2.4 > means 'the distutils included with Python 2.4'. Easier to remember that > distutils 1.0.4 was the version released with 2.4. > > If it makes sense, I can take the resposibility to increase the version > number with each release, and update the corresponding PEPs, but I won't > object to the 'change API, bump version number' scheme as well. If you want to stick with the Python version, you might as well replace __version__ in distutils/__init__.py with sys.version[:5]. However, this breaks badly if you want to install a stand-alone version of distutils in a previous version of Python or another variant of Python such as IronPython, Jython, etc. distutils still is very much an independent piece of software which only happens to be shipped together with core Python. I would rather like to see it stay that way to make life easier for the developers of Python add-ons, so my vote is for the standard "change API, bump version number" scheme. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Jan 6 21:05:47 2005 From: theller at python.net (Thomas Heller) Date: Thu Jan 6 21:04:29 2005 Subject: [Distutils] distutils version numbering In-Reply-To: <41DD3ADE.8000901@egenix.com> (M.'s message of "Thu, 06 Jan 2005 14:19:26 +0100") References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> <41DD0E1E.3090106@egenix.com> <41DD3ADE.8000901@egenix.com> Message-ID: > distutils still is very much an independent piece of software > which only happens to be shipped together with core Python. > I would rather like to see it stay that way to make life > easier for the developers of Python add-ons, so my vote is > for the standard "change API, bump version number" scheme. Fine with me. I have fixed a bug in 2.4's bdist_wininst already (*), although that's not an api change. What should the next version numbers be then, in the release24-maint branch and HEAD? Thomas (*) One of my own, personal use cases for the distutils version number is that I want to be able to identify the distutils version a binary windows installer was built with - it is displayed on the first screen if you run it. From mal at egenix.com Fri Jan 7 12:27:20 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 7 12:27:24 2005 Subject: [Distutils] distutils version numbering In-Reply-To: References: <41DC5AF1.6060001@sympatico.ca> <41DC6074.2090204@egenix.com> <41DD0E1E.3090106@egenix.com> <41DD3ADE.8000901@egenix.com> Message-ID: <41DE7218.1080600@egenix.com> Thomas Heller wrote: >>distutils still is very much an independent piece of software >>which only happens to be shipped together with core Python. >>I would rather like to see it stay that way to make life >>easier for the developers of Python add-ons, so my vote is >>for the standard "change API, bump version number" scheme. > > > Fine with me. > > I have fixed a bug in 2.4's bdist_wininst already (*), although that's > not an api change. What should the next version numbers be then, in the > release24-maint branch and HEAD? Patches only: 2.4.1 API changes and new features: 2.5.0 If we introduce a new feature for every Python release, we'll remain in sync ;-) > Thomas > > (*) One of my own, personal use cases for the distutils version number > is that I want to be able to identify the distutils version a binary > windows installer was built with - it is displayed on the first screen > if you run it. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From webmaster at smallco.com Fri Jan 7 20:36:48 2005 From: webmaster at smallco.com (Webmaster) Date: Fri Jan 7 20:37:01 2005 Subject: [Distutils] Automatic response to your mail (Error) Message-ID: The automatic reply to this e-mail which you should have received in response to your e-mail to webmaster@smallco.com has not been defined. Please contact postmaster@smallco.com for assistance. From webmaster at smallco.com Sat Jan 8 14:26:11 2005 From: webmaster at smallco.com (Webmaster) Date: Sat Jan 8 14:26:15 2005 Subject: [Distutils] Automatic response to your mail (Error) Message-ID: The automatic reply to this e-mail which you should have received in response to your e-mail to webmaster@smallco.com has not been defined. Please contact postmaster@smallco.com for assistance. From bustamam98 at yahoo.com Mon Jan 10 17:51:32 2005 From: bustamam98 at yahoo.com (bustamam98@yahoo.com) Date: Mon Jan 10 17:51:38 2005 Subject: [Distutils] Yahoo! Auto Response Message-ID: <20050110165136.622531E400E@bag.python.org> A non-text attachment was scrubbed... Name: not available Type: text Size: 1079 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20050110/58b03fb6/attachment.ksh From titus at caltech.edu Fri Jan 14 20:08:23 2005 From: titus at caltech.edu (Titus Brown) Date: Fri Jan 14 20:08:26 2005 Subject: [Distutils] 'clean' and '--help' suggestions. Message-ID: <20050114190823.GB10937@caltech.edu> Hi folks, I've been using distutils to package Python extensions for two packages, and I keep stumbling across two different issues with 'setup.py' usage. The first is the behavior of 'clean': --help-commands says clean clean up output of 'build' command which (to me) meant that 'python setup.py clean' would remove my build directory. Instead, it means 'remove temporary files but leave stuff under build/lib'. Apparently 'clean --all' is what you need to use to get this behavior. I'd suggest changing the --help-commands string to say clean clean up temporary files from 'build' command or some such. Alternatively, make '--all' the default behavior, and have '--temp-only' retain lib.* files. (My expected behavior of 'clean' comes from C Makefiles, where 'clean' means 'remove all object files and force recompilation.) -- The second issue is with the default --help behavior. I find that 'python setup.py --help' returns information that's not very useful to package *installers*, who usually only care about 'build' and 'install'. I'd strongly recommend having '--help' return more up-front information about build, install, and clean. Perhaps something like """ Commonly-used commands: (see --help-commands for more information) build build everything needed to install install install everything from build directory clean clean up output of 'build' command """ in front of the current output. Thanks for bearing with my whining ;). If a set of changes can be agreed upon, I'd be happy to make the changes & submit patches. cheers, --titus From titus at caltech.edu Fri Jan 14 20:15:21 2005 From: titus at caltech.edu (Titus Brown) Date: Fri Jan 14 20:15:23 2005 Subject: [Distutils] Question re extension modules. Message-ID: <20050114191521.GC10937@caltech.edu> Hi again, I'm developing a C++ library & associated extension module within the same directory. My setup.py contains this line: parser_mod = Extension("paircomp._paircomp_parser", ["c++-ext/_paircomp_parser.cc",], include_dirs=['../lib',], library_dirs=['../lib',], libraries=['paircomp', 'stdc++']) One of the important libraries that I need to include is -lpaircomp, in '../lib/libpaircomp.a'. Currently when I change libpaircomp.a (by, for example, making some internal change to the C++ library that's not reflected in the API) my Python extensions do not get recompiled by 'python setup.py build'. (This is run automatically by the Makefile.) So at the moment I either have to use Makefile trickery or just do an 'rm -fr build' to force recompilation of the extension when the library is changed. Is there a canonical way to tell distutils that 'this extension depends on this file, so force rebuild if the file changes'? One obvious possibility would be to simple compare last-changed dates on all of the libraries with last-changed dates on the .so file produced by setup.py. thanks, --titus From yarden at umd.edu Sat Jan 15 19:52:12 2005 From: yarden at umd.edu (Yarden Katz) Date: Sat Jan 15 19:53:35 2005 Subject: [Distutils] Trouble packaging data files. Message-ID: <86ekgm4jab.fsf@umd.edu> Hi. I'm trying to distribute a piece of software and I'm able to get distutils to package all of my *.py modules, which are in a single package, correctly. However, I've been unable to get it to package any of the data files. I wrote the following setup.py file: setup(name='pychinko', version='0.1', ... packages=['pychinko'], data_files = [('ruletests/rules', ['ruletests/rules/spoRules.n3'])], package_dir = {'pychinko': '.'}, package_data = {'pychinko': ['ruletests/rules/spoRules.n3']}) But both data_files and package_data lines (and some variations on them) are ignored when I run "python setup.py sdist". The pychinko package is included correctly, but none of the data files are. When it's packaged I get something like: creating pychinko-0.1 making hard links in pychinko-0.1... hard linking setup.py -> pychinko-0.1 hard linking ./__init__.py -> pychinko-0.1/. hard linking ./afon.py -> pychinko-0.1/. hard linking ./builtins.py -> pychinko-0.1/. hard linking ./config.py -> pychinko-0.1/. ... But again, no data files at all. Any idea what could be doing this? My dir structure looks something like this: pychinko/ setup.py foo.py bar.py ... ruletests/ rules/ ... Thanks a lot, appreciate your help, -- Yarden Katz | Mind the gap From jafo at tummy.com Sun Jan 16 01:38:54 2005 From: jafo at tummy.com (Sean Reifschneider) Date: Sun Jan 16 01:39:27 2005 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <20041025101540.GA14892@treasure> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041025101540.GA14892@treasure> Message-ID: <20050116003854.GC2701@tummy.com> It looks like some good progress has been made on this front since the original posting. Are we at a point where it's ready to be checked in now? Thoughts? Thanks, Sean -- moshez is not afraid of commitment. "Yes, honey, I'm ready for commitment. Why, I commit to numerous CVS projects" Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From oliver.schoenborn at utoronto.ca Sun Jan 16 14:01:34 2005 From: oliver.schoenborn at utoronto.ca (Oliver Schoenborn) Date: Sun Jan 16 14:01:50 2005 Subject: [Distutils] Trouble packaging data files. In-Reply-To: <86651y4hl9.fsf@umd.edu> References: <86ekgm4jab.fsf@umd.edu> <41E96C24.2030800@utoronto.ca> <86651y4hl9.fsf@umd.edu> Message-ID: <41EA65AE.3060904@utoronto.ca> Yarden Katz wrote: >Oliver Schoenborn writes: > > >>I would guess it's your (possibly missing) MANIFEST file, which should >>include a line for the data stuff. >> >> >If I "rm MANIFEST" and let distutils recreate it, the problem doesn't change. Am I supposed to manually edit MANIFEST? > > Actually, I meant the MANIFEST*.in* file: AFAIR, sdist only includes certain known files (*.py etc) and you have to tell it what else to include in the MANIFEST.in file. The MANIFEST file is automatically generated if it doesn't exist. OTOH, I think you can directly create a MANIFEST file, it does not get overwritten if it already exists *and *there is no *.in* file. I have refactored the manifest code into a separate module that you can use for packaging data for other build commands, such as bdist, let me know if you would like to give it a try (haven't had time to submit it as a patch yet). I used it to package a database and config files etc with my distribution. Oliver From mal at egenix.com Mon Jan 17 10:24:31 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 17 10:24:34 2005 Subject: [Distutils] Question re extension modules. In-Reply-To: <20050114191521.GC10937@caltech.edu> References: <20050114191521.GC10937@caltech.edu> Message-ID: <41EB844F.6080000@egenix.com> Titus Brown wrote: > Hi again, > > I'm developing a C++ library & associated extension module within the > same directory. My setup.py contains this line: > > parser_mod = Extension("paircomp._paircomp_parser", > ["c++-ext/_paircomp_parser.cc",], > include_dirs=['../lib',], > library_dirs=['../lib',], > libraries=['paircomp', 'stdc++']) > > One of the important libraries that I need to include is -lpaircomp, > in '../lib/libpaircomp.a'. > > Currently when I change libpaircomp.a (by, for example, making some > internal change to the C++ library that's not reflected in the API) > my Python extensions do not get recompiled by 'python setup.py build'. > (This is run automatically by the Makefile.) distutils doesn't do dependency tracking like make. > So at the moment I either have to use Makefile trickery or just do an > 'rm -fr build' to force recompilation of the extension when the library > is changed. > > Is there a canonical way to tell distutils that 'this extension depends > on this file, so force rebuild if the file changes'? No. > One obvious possibility would be to simple compare last-changed dates > on all of the libraries with last-changed dates on the .so file > produced by setup.py. distutils is a tool for packaging code, not a replacement for development tools like make. You normally only run distutils setup.py scripts after you've completed developing your code. make is a much better tool for dependency checking, so the "right" way to handle the dependency problem is to add proper targets to the Makefile. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 17 10:29:51 2005 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 17 10:29:53 2005 Subject: [Distutils] 'clean' and '--help' suggestions. In-Reply-To: <20050114190823.GB10937@caltech.edu> References: <20050114190823.GB10937@caltech.edu> Message-ID: <41EB858F.3050301@egenix.com> Titus Brown wrote: > Hi folks, > > I've been using distutils to package Python extensions for two packages, > and I keep stumbling across two different issues with 'setup.py' usage. > > The first is the behavior of 'clean': --help-commands says > > clean clean up output of 'build' command > > which (to me) meant that 'python setup.py clean' would remove my > build directory. Instead, it means 'remove temporary files but > leave stuff under build/lib'. Apparently 'clean --all' is what > you need to use to get this behavior. > > I'd suggest changing the --help-commands string to say > > clean clean up temporary files from 'build' command > > or some such. Alternatively, make '--all' the default behavior, > and have '--temp-only' retain lib.* files. +1 on the help string change. +0 on making --all the default. > (My expected behavior of 'clean' comes from C Makefiles, where 'clean' > means 'remove all object files and force recompilation.) > > -- > > The second issue is with the default --help behavior. I find that > 'python setup.py --help' returns information that's not very useful > to package *installers*, who usually only care about 'build' and > 'install'. I'd strongly recommend having '--help' return more > up-front information about build, install, and clean. Perhaps something > like > > """ > Commonly-used commands: (see --help-commands for more information) > > build build everything needed to install > install install everything from build directory > clean clean up output of 'build' command > """ > > in front of the current output. I'd suggest adding a few common examples to the --help output. > Thanks for bearing with my whining ;). If a set of changes can be > agreed upon, I'd be happy to make the changes & submit patches. Please post the patches to SourceForge. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Michael.Foord at tbsmerchants.co.uk Mon Jan 17 12:58:23 2005 From: Michael.Foord at tbsmerchants.co.uk (Michael Foord) Date: Mon Jan 17 12:58:28 2005 Subject: [Distutils] distutils bug Message-ID: <41EBA85F.3020100@tbsmerchants.co.uk> I've had some problems with py2exe which I *think* highlights a bug in distutils. I had a mysterious problems with py2exe causing a 'crash' - not an exception but a full on windows 'the memory referenced could not be read' crash. I could reproduce this problem on two machines - (both windows XP) one with python 2.3 and another with python 2.4, however no-one else had the same problem. In order to trace the exact point the crash was occurring I set the DISTUTILS_DEBUG environment variable. The crash I was investigating then disapeared (I told you it was mysterious) - but I got a traceback from within distutils. The traceback occurs within distutils.command.install - the 'dump_dirs' function in install.py. The offending code is : val = getattr(self, opt_name) print " %s: %s" % (opt_name, val) when run from py2exe this causes an AttributeError for the 'no_compile' attribute. If replaced with the following code, it works fine. try: val = getattr(self, opt_name) except AttributeError: print 'Attribute not found :', opt_name else: print " %s: %s" % (opt_name, val) (This is for the Movable Python project - which works fine :-) Regards, Fuzzyman http://www.voidspace.org.uk/python/index.shtml From calvin at users.sourceforge.net Mon Jan 17 13:38:39 2005 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Mon Jan 17 13:38:42 2005 Subject: [Distutils] distutils bug In-Reply-To: <41EBA85F.3020100@tbsmerchants.co.uk> References: <41EBA85F.3020100@tbsmerchants.co.uk> Message-ID: <20050117123839.GA6409@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, Jan 17, 2005 at 11:58:23AM +0000, Michael Foord wrote: > The traceback occurs within distutils.command.install - the 'dump_dirs' > function in install.py. The crash occurs when you use negated options and turn on debugging. I thought I submitted a patch for this bug ages ago - but cannot find the thing in the SF patch tracker any more. Hmm, must have sent it only to the list or whatever. Anyway, I created a new patch (against CVS) here: https://sourceforge.net/tracker/index.php?func=detail&aid=1103844&group_id=5470&atid=305470 Regards, Bastian - -- ,''`. Bastian Kleineidam : :' : GnuPG Schl?ssel `. `' gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB67HPeBwlBDLsbz4RAsWpAKC3k5Wc2xG6WrMSTLKmcJd1XNFiCACZAa+m 0jjTkNO6SFGMwtCFoPcqKFk= =805I -----END PGP SIGNATURE----- From titus at caltech.edu Mon Jan 17 20:53:29 2005 From: titus at caltech.edu (Titus Brown) Date: Mon Jan 17 20:53:37 2005 Subject: [Distutils] 'clean' and '--help' suggestions. In-Reply-To: <41EB858F.3050301@egenix.com> References: <20050114190823.GB10937@caltech.edu> <41EB858F.3050301@egenix.com> Message-ID: <20050117195329.GA16018@caltech.edu> -> Please post the patches to SourceForge. patch at http://issola.caltech.edu/~t/transfer/python-distutils-help-patch patch 1104111 on SF w/patch file attached. --- % python setup.py --help Common commands: (see '--help-commands' for more) setup.py build will build the package underneath 'build/' setup.py install will install the package Global options: ... --- and --- % python setup.py --help-commands Standard commands: ... clean clean up temporary files from 'build' command ... --- Also note that on http://www.python.org/sigs/distutils-sig/cvs.html the CVS hostname needs to be changed to 'cvs.sf.net' from 'cvs.python.sf.net' to accomodate changes in SF... cheers, --titus From fdrake at acm.org Mon Jan 17 21:36:17 2005 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Jan 17 21:36:25 2005 Subject: [Distutils] 'clean' and '--help' suggestions. In-Reply-To: <20050117195329.GA16018@caltech.edu> References: <20050114190823.GB10937@caltech.edu> <41EB858F.3050301@egenix.com> <20050117195329.GA16018@caltech.edu> Message-ID: <200501171536.17579.fdrake@acm.org> On Monday 17 January 2005 14:53, Titus Brown wrote: > Also note that on > > http://www.python.org/sigs/distutils-sig/cvs.html > > the CVS hostname needs to be changed to 'cvs.sf.net' from > 'cvs.python.sf.net' to accomodate changes in SF... Done; thanks for pointing this out! -Fred -- Fred L. Drake, Jr. From dairiki at gmail.com Tue Jan 18 00:18:59 2005 From: dairiki at gmail.com (Jeff Dairiki) Date: Tue Jan 18 00:19:01 2005 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <20050116003854.GC2701@tummy.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041025101540.GA14892@treasure> <20050116003854.GC2701@tummy.com> Message-ID: <4063f01205011715184e6ff9ed@mail.gmail.com> On Sat, 15 Jan 2005 17:38:54 -0700, Sean Reifschneider wrote: > It looks like some good progress has been made on this front since the > original posting. Are we at a point where it's ready to be checked in now? > Thoughts? I (the author of the patch) say it's ready. On the other hand, I haven't really heard a lot of feedback on it from, e.g., higher ups in the debian-python world, so you may or may not want to take my opinion with a grain of salt. Jeff From calvin at users.sourceforge.net Tue Jan 18 12:56:47 2005 From: calvin at users.sourceforge.net (Bastian Kleineidam) Date: Tue Jan 18 12:56:51 2005 Subject: [Distutils] bdist_deb (was: Extending distutils with 3rd party build commands?) In-Reply-To: <4063f01205011715184e6ff9ed@mail.gmail.com> References: <1098548601.17693.14.camel@hairball.dairiki.org> <417CBDAD.9050505@egenix.com> <20041025101540.GA14892@treasure> <20050116003854.GC2701@tummy.com> <4063f01205011715184e6ff9ed@mail.gmail.com> Message-ID: <20050118115647.GA28113@treasure> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, Jan 17, 2005 at 03:18:59PM -0800, Jeff Dairiki wrote: > On the other hand, I haven't really heard a lot of feedback on it > from, e.g., higher ups > in the debian-python world, so you may or may not want to take my opinion with > a grain of salt. I reviewed the patch by testing it on the LinkChecker package (http://sf.net/projects/linkchecker). - - The remove_tree method in bdist_deb is also available in dir_utils.py. I think it can be replaced with from distutils.dir_utils import remove_tree - - The bdist_deb.in_directory() utility function should probably be moved to spawn.py so that other commands can use it too. - - There is not a way to supply additional debuild options. My current debuild options are used for signing the package (-pgpg -sgpg -k$(GPGKEY)), and running automated package checks linda and lintian (--linda --lintian-opts -i --linda-opts -i). It might not be a bad idea to supply a generic --debuild-opts and --dpkg-buildpackage-opts since I think most developers use different options for debuild. - - The dh_make command puts (in my case) the complete GPL text in debian/copyright. To reduce disk usage the preferred way is to mention only the name and refer to the complete text in /usr/share/common-licenses, ie. License: GPL , see /usr/share/common-licenses/GPL for more info. Currently available entries in common-licenses directory: - -rw-r--r-- 1 root 6111 Dec 16 1996 Artistic - -rw-r--r-- 1 root 1499 Aug 26 1999 BSD lrwxrwxrwx 1 root 5 Dec 17 14:04 GPL -> GPL-2 - -rw-r--r-- 1 root 17992 Sep 16 1999 GPL-2 lrwxrwxrwx 1 root 8 Dec 17 14:04 LGPL -> LGPL-2.1 - -rw-r--r-- 1 root 25284 Feb 2 2000 LGPL-2 - -rw-r--r-- 1 root 26528 Jul 21 2003 LGPL-2.1 - - The generated debian/rules executes dh_python. This needs a build dependency on python which is currently not there. - - When running debuild standalone (after python setup.py dh_make), generating the PKG-INFO file fails in the case when setup.py imports additional modules at the top. Here is the error I get: $ debuild binary generating debian/PKG-INFO Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.5/distutils/core.py", line 218, in run_setup execfile(script_name, g, l) File "setup.py", line 292, in ? include_dirs = include_dirs + \ File "setup.py", line 53, in normpath return os.path.normpath(path) NameError: global name 'os' is not defined make: *** [debian/PKG-INFO] Fehler 1 The 'os' module is imported in setup.py at the top. - - After running python setup.py dh_make there should be a note reminding the packager that he has to review and edit the generated files in the debian/ subdirectory. - - Manpage stubs debian/*.1 for the scripts should only be generated when such a file is not already installed. For example the setup.py from LinkChecker already installs manpages when running on POSIX platforms: [...] data_files.append(('share/man/man1', ['doc/en/linkchecker.1'])) data_files.append(('share/man/de/man1', ['doc/de/linkchecker.1'])) data_files.append(('share/man/fr/man1', ['doc/fr/linkchecker.1'])) [...] - - Both commands dh_make and bdist_deb should probably not be run on non-POSIX platforms. This should be documented. If you run it on eg. a Windows platform, an appropriate error message should be printed, something like this: if os.name != 'posix': print "This command is only available on POSIX systems" print "Your current system is %s (%s)." % (os.name, sys.platform) sys.exit(1) - - dh_make should also support generating packages relying on the "default" Python version (according to section 3.1 of the Debian Python Policy). This means there is a single package name (without the "python-" prefix) depending on python (>= 2.3), python (<< 2.4). Well, that's it for now :) Regards, Bastian - -- ,''`. Bastian Kleineidam : :' : GnuPG Schlssel `. `' gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB7Pl/eBwlBDLsbz4RAhFZAKCLbxrNrjFGqdC5Ad+vB/7vB0V0QACfff+G Bd/dWB8RPrmpSURUAEktLCk= =Ae8k -----END PGP SIGNATURE----- From zeisberg at informatik.uni-freiburg.de Wed Jan 19 17:18:49 2005 From: zeisberg at informatik.uni-freiburg.de (Uwe Zeisberger) Date: Wed Jan 19 17:18:53 2005 Subject: [Distutils] distribution of an embedding application Message-ID: <20050119161849.GA22931@informatik.uni-freiburg.de> Hello, I coded a simple application in C, which embeds python. Now I want to distribute this program using distutils. In the documentation of distutils I found the usual ways to build and install python scripts and modules. Is there a way to use distutils to build my application, too? Something like: --8<-- from distutils.core import setup setup(name="foo", applications=[Application("foo", ["foo.c"])]) --8<-- Regards Uwe -- Uwe Zeisberger http://www.google.com/search?q=30+hours+and+4+days+in+seconds From mbakker at engr.uga.edu Thu Jan 20 00:15:48 2005 From: mbakker at engr.uga.edu (Mark Bakker) Date: Thu Jan 20 00:17:03 2005 Subject: [Distutils] Distrubiting an extension w/o source Message-ID: <41EEEA24.9070403@engr.uga.edu> Hello - I am trying to make a windows install for my Python program. The program includes one FORTRAN extension, which I compiled into a working .pyd file. My question is how to include the .pyd file in the distribution. In the 'extension' part of the manual you only talk about compiling from source. I have already compiled it (and it works!), just want to add it to my other files. Thanks, Mark From theller at python.net Thu Jan 20 19:59:12 2005 From: theller at python.net (Thomas Heller) Date: Thu Jan 20 19:57:58 2005 Subject: [Distutils] Re: distribution of an embedding application References: <20050119161849.GA22931@informatik.uni-freiburg.de> Message-ID: Uwe Zeisberger writes: > Hello, > > I coded a simple application in C, which embeds python. Now I want to > distribute this program using distutils. > > In the documentation of distutils I found the usual ways to build and install > python scripts and modules. > > Is there a way to use distutils to build my application, too? Something like: > > --8<-- > from distutils.core import setup > > setup(name="foo", applications=[Application("foo", ["foo.c"])]) > > --8<-- Not directly. But you can customize the commands that distutils uses, the py2exe setup could serve as an example. Thomas