From Juergen Hermann" Message-ID: On Thu, 31 Oct 2002 14:38:45 -0500, A.M. Kuchling wrote: >On Thu, Oct 31, 2002 at 10:24:41AM +0200, Juergen Hermann wrote: >> from distutils.dist import Distribution >> assert hasattr(Distribution, "getSupportedOptions") >> assert "foo" in Distribution.getSupportedOptions() > >Now that I look at, why would this be a method on Distribution? Because that is the class the setup attributes are finally handed into. = Of course, a function in core.py is ok, too. Whether the list should initially be empty or contain the currently handled attributes is a point too (but I have no real preference). Ciao, J=FCrgen -- J=FCrgen Hermann, Developer WEB.DE AG, http://webde-ag.de/ From jeremy@alum.mit.edu Tue Nov 5 15:57:04 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Tue Nov 5 15:57:04 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <20021105205040.GA25678@ute.mems-exchange.org> References: <20021105205040.GA25678@ute.mems-exchange.org> Message-ID: <15816.12364.168272.536845@slothrop.zope.com> >>>>> "AMK" == Andrew Kuchling writes: AMK> On Tue, Nov 05, 2002 at 12:11:11PM -0800, AMK> jhylton@users.sourceforge.net wrote: >> Remove use of string module and reflow a couple of long lines. AMK> Note that the use of string methods means the end of 1.5.2 AMK> compatibility. If we're doing that, then there are many more AMK> modernizations that can be done to the Distutils code. Excellent point! Do people sitll care about Python 1.5.2 support moving forward? I'd propose to make the last distutils release for 1.5.2 the final release and make distutils conform to modern Python. Jeremy From jeremy@alum.mit.edu Tue Nov 5 16:07:02 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Tue Nov 5 16:07:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <15816.12364.168272.536845@slothrop.zope.com> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> Message-ID: <15816.12968.587791.253396@slothrop.zope.com> It doesn't appear that there has been any interest in standalone distutils releases since Python 2.2 was released. I just checked and saw that the last release of distutils separate from Python was 1.0.2. This release was done around April 2001. And, suggesting that April is not the cruelest month after all, Python 1.5.2 was released in April 1999. I'm happy to let the winter snow cover over 1.5.2 support and forget it come spring of 2003 and a Python 2.3 final release. Jeremy From thomas.heller@ion-tof.com Tue Nov 5 16:18:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Nov 5 16:18:01 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <15816.12968.587791.253396@slothrop.zope.com> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <15816.12968.587791.253396@slothrop.zope.com> Message-ID: Jeremy Hylton writes: > It doesn't appear that there has been any interest in standalone > distutils releases since Python 2.2 was released. > > I just checked and saw that the last release of distutils separate > from Python was 1.0.2. This release was done around April 2001. And, > suggesting that April is not the cruelest month after all, Python > 1.5.2 was released in April 1999. I'm happy to let the winter snow > cover over 1.5.2 support and forget it come spring of 2003 and a > Python 2.3 final release. > I have (totally unofficially) distributed CVS versions of distutils to several people, so that they can try out the recent bdist_wininst improvements. I was thinking that maybe we (who is we?) should release a new distutils version when this is finished, but I'm not sure if there are still Python 1.5.2 users out there. With the current state, it would be easy to do this last release even compatible for them, and after that we could move on with new cool coding styles, and using new features. Thomas From amk@amk.ca Tue Nov 5 22:24:01 2002 From: amk@amk.ca (A.M. Kuchling) Date: Tue Nov 5 22:24:01 2002 Subject: [Distutils] 1.5.2 compatibility In-Reply-To: ; from thomas.heller@ion-tof.com on Tue, Nov 05, 2002 at 10:17:19PM +0100 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <15816.12968.587791.253396@slothrop.zope.com> Message-ID: <20021105225336.A29021@nyman.amk.ca> On Tue, Nov 05, 2002 at 10:17:19PM +0100, Thomas Heller wrote: >I was thinking that maybe we (who is we?) should release a new >distutils version when this is finished, but I'm not sure if there are >still Python 1.5.2 users out there. We could roll a Distutils 1.0.3 release from the code that's in Python 2.2.2 (assuming no 2.x-isms crept in). Maybe that will be enough for the 1.5.2 holdouts? If not, then a further Distutils 1.0.4 can come from the Distutils code in 2.3, once the use of string methods is backed out. --amk From mal@lemburg.com Wed Nov 6 12:25:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Nov 6 12:25:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> Message-ID: <3DC94FF0.4050902@lemburg.com> Jeremy Hylton wrote: >>>>>>"AMK" == Andrew Kuchling writes: > > > AMK> On Tue, Nov 05, 2002 at 12:11:11PM -0800, > AMK> jhylton@users.sourceforge.net wrote: > >> Remove use of string module and reflow a couple of long lines. > > AMK> Note that the use of string methods means the end of 1.5.2 > AMK> compatibility. If we're doing that, then there are many more > AMK> modernizations that can be done to the Distutils code. > > Excellent point! > > Do people sitll care about Python 1.5.2 support moving forward? I'd > propose to make the last distutils release for 1.5.2 the final release > and make distutils conform to modern Python. -1. Python 1.5.2 is still in active use out there. It's not worth breaking code just for cosmetic reasons. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Wed Nov 6 12:28:07 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Nov 6 12:28:07 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <15816.12968.587791.253396@slothrop.zope.com> Message-ID: <3DC950AC.7010909@lemburg.com> Thomas Heller wrote: > Jeremy Hylton writes: > > >>It doesn't appear that there has been any interest in standalone >>distutils releases since Python 2.2 was released. >> >>I just checked and saw that the last release of distutils separate >>from Python was 1.0.2. This release was done around April 2001. And, >>suggesting that April is not the cruelest month after all, Python >>1.5.2 was released in April 1999. I'm happy to let the winter snow >>cover over 1.5.2 support and forget it come spring of 2003 and a >>Python 2.3 final release. >> > > > I have (totally unofficially) distributed CVS versions of distutils to > several people, so that they can try out the recent bdist_wininst > improvements. > > I was thinking that maybe we (who is we?) should release a new > distutils version when this is finished, but I'm not sure if there are > still Python 1.5.2 users out there. There are. > With the current state, it would be easy to do this last release even > compatible for them, and after that we could move on with new cool > coding styles, and using new features. Provided that new coding styles retain Python 2.1 compatibility, +0, otherwise -1. In distutils, performance is not relevant, so new coding styles wouldn't buy us anything much. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mwh@python.net Wed Nov 6 13:32:01 2002 From: mwh@python.net (Michael Hudson) Date: Wed Nov 6 13:32:01 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: "M.-A. Lemburg"'s message of "Wed, 06 Nov 2002 18:22:56 +0100" References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> Message-ID: <2mbs52pn2d.fsf@starship.python.net> "M.-A. Lemburg" writes: > Python 1.5.2 is still in active use out there. It's not worth > breaking code just for cosmetic reasons. But are these 1.5.2 users going to see any new distutils code? I.e. do people who still run 1.5.2 occasionally upgrade their distutils installation? I'd be surprised, but could always be wrong. It would be a good idea to leave the last 1.5.2 compatible released distutils tarball somewhere prominent in any case. Cheers, M. -- Every now and then, Google doesn't throw up what I need so I start checking Altavista, Yahoo, etc. In almost every single case, I am brutally reminded why I use Google in the first place. -- John Riddoch, asr From jeremy@alum.mit.edu Wed Nov 6 13:48:02 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Wed Nov 6 13:48:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <2mbs52pn2d.fsf@starship.python.net> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> Message-ID: <15817.25485.566136.459965@slothrop.zope.com> >>>>> "MH" == Michael Hudson writes: MH> "M.-A. Lemburg" writes: >> Python 1.5.2 is still in active use out there. It's not worth >> breaking code just for cosmetic reasons. MH> But are these 1.5.2 users going to see any new distutils code? MH> I.e. do people who still run 1.5.2 occasionally upgrade their MH> distutils installation? I'd be surprised, but could always be MH> wrong. MH> It would be a good idea to leave the last 1.5.2 compatible MH> released distutils tarball somewhere prominent in any case. Python 1.5.2 users have been running with distutils 1.0.2 for about a year and a half now. We haven't heard any complaints from them about the lack of releases for 1.5.2. I believe the last release was good enough for 1.5.2. If someone can live with all the bugs and out-of-date stuff in 1.5.2, they can live with a slightly out-of-date distutils, too. It's a pain in the neck to hack on distutils and be careful to avoid accidentally adding code that won't work with 1.5.2. Jeremy From robin@jessikat.fsnet.co.uk Wed Nov 6 13:51:23 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Wed Nov 6 13:51:23 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <2mbs52pn2d.fsf@starship.python.net> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> Message-ID: In article <2mbs52pn2d.fsf@starship.python.net>, Michael Hudson writes >"M.-A. Lemburg" writes: > >> Python 1.5.2 is still in active use out there. It's not worth >> breaking code just for cosmetic reasons. > >But are these 1.5.2 users going to see any new distutils code? >I.e. do people who still run 1.5.2 occasionally upgrade their >distutils installation? I'd be surprised, but could always be wrong. > >It would be a good idea to leave the last 1.5.2 compatible released >distutils tarball somewhere prominent in any case. > >Cheers, >M. > I'm one of the unlucky ones with 1.5.2/2.0/2.1 and 2.3. In practice each has the very latest implementation and (touch wood) so far I've had no real problems. The problem is that when feature X is advertised ie a better way to do libraries/dlls or whatever that usually goes into the setup.py. I don't maintain a separate client code base so the 1.5.2 should compile/build with the same setup.py as the bleeding edge. I suspect that I won't need to maintain 1.5.2 forever, but the spread is quite wide without adding build dependencies in. -- Robin Becker From mal@lemburg.com Wed Nov 6 13:55:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Nov 6 13:55:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> Message-ID: <3DC96538.6030700@lemburg.com> Michael Hudson wrote: > "M.-A. Lemburg" writes: > > >>Python 1.5.2 is still in active use out there. It's not worth >>breaking code just for cosmetic reasons. > > > But are these 1.5.2 users going to see any new distutils code? > I.e. do people who still run 1.5.2 occasionally upgrade their > distutils installation? I'd be surprised, but could always be wrong. Sure, because that can sometimes be the only way to get more recent distutils packages installed from source. > It would be a good idea to leave the last 1.5.2 compatible released > distutils tarball somewhere prominent in any case. Indeed. We should probably wrap up the current version and just place it out there for people to download. If you could tell me where to upload the files, I could easily generate a snapshot of the current distutils version as 1.0.4beta and post them there. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Wed Nov 6 14:00:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Nov 6 14:00:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <3DC96538.6030700@lemburg.com> Message-ID: <3DC9663D.2010508@lemburg.com> M.-A. Lemburg wrote: > Michael Hudson wrote: >> It would be a good idea to leave the last 1.5.2 compatible released >> distutils tarball somewhere prominent in any case. > > > Indeed. We should probably wrap up the current version and just > place it out there for people to download. > > If you could tell me where to upload the files, I could easily > generate a snapshot of the current distutils version as 1.0.4beta > and post them there. Of course, Jeremy will have to back out the string method changes. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jeremy@alum.mit.edu Wed Nov 6 14:07:15 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Wed Nov 6 14:07:15 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <3DC9663D.2010508@lemburg.com> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <3DC96538.6030700@lemburg.com> <3DC9663D.2010508@lemburg.com> Message-ID: <15817.26576.309047.835241@slothrop.zope.com> >>>>> "MAL" == mal writes: MAL> Of course, Jeremy will have to back out the string method MAL> changes. We can just create a distutils-final-1-5-2-support tag with the previous revision of the file and make the release from that. Jeremy From mal@lemburg.com Wed Nov 6 14:08:25 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Nov 6 14:08:25 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <15817.25485.566136.459965@slothrop.zope.com> Message-ID: <3DC96801.2000904@lemburg.com> Jeremy Hylton wrote: >>>>>>"MH" == Michael Hudson writes: > > > MH> "M.-A. Lemburg" writes: > >> Python 1.5.2 is still in active use out there. It's not worth > >> breaking code just for cosmetic reasons. > > MH> But are these 1.5.2 users going to see any new distutils code? > MH> I.e. do people who still run 1.5.2 occasionally upgrade their > MH> distutils installation? I'd be surprised, but could always be > MH> wrong. > > MH> It would be a good idea to leave the last 1.5.2 compatible > MH> released distutils tarball somewhere prominent in any case. > > Python 1.5.2 users have been running with distutils 1.0.2 for about a > year and a half now. We haven't heard any complaints from them about > the lack of releases for 1.5.2. Maybe that's because package developers have tried to keep 1.5.2 compatibility by adding bug fixes to their setup.pys ?! I know that I've done this in the past. > I believe the last release was good > enough for 1.5.2. If someone can live with all the bugs and > out-of-date stuff in 1.5.2, they can live with a slightly out-of-date > distutils, too. If they won't be able to compile distutils packages anymore, they certainly won't feel good about it. > It's a pain in the neck to hack on distutils and be careful to avoid > accidentally adding code that won't work with 1.5.2. Huh ? Avoiding string methods isn't all that hard. Instead of discussing code cosmetics we should look into adding more packagers for e.g. debian and freebsd. These things are much more important, IMHO. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jeremy@alum.mit.edu (Jeremy Hylton) Wed Nov 6 14:17:01 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) (Jeremy Hylton) Date: Wed Nov 6 14:17:01 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 In-Reply-To: <3DC96801.2000904@lemburg.com> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <15817.25485.566136.459965@slothrop.zope.com> <3DC96801.2000904@lemburg.com> Message-ID: <15817.27244.644338.808306@slothrop.zope.com> >>>>> "MAL" == mal writes: >> Python 1.5.2 users have been running with distutils 1.0.2 for >> about a year and a half now. We haven't heard any complaints >> from them about the lack of releases for 1.5.2. MAL> Maybe that's because package developers have tried to keep MAL> 1.5.2 compatibility by adding bug fixes to their setup.pys ?! MAL> I know that I've done this in the past. Examples, please. I don't maintain any software that is intended to run with 1.5.2, so I can't quite imagine what you mean. >> I believe the last release was good enough for 1.5.2. If someone >> can live with all the bugs and out-of-date stuff in 1.5.2, they >> can live with a slightly out-of-date distutils, too. MAL> If they won't be able to compile distutils packages anymore, MAL> they certainly won't feel good about it. I don't think anyone has suggested making changes such that would prevent people from building distutils packages. I just don't understand the fear here. >> It's a pain in the neck to hack on distutils and be careful to >> avoid accidentally adding code that won't work with 1.5.2. MAL> Huh ? Avoiding string methods isn't all that hard. In large software projects like Zope and Mailman, people have repeatedly run into problems with Python version compatibility. There are lots of differences between 1.5.2 and 2.2.2, and it is easy to use a new feature without thinking "I'm using a new feature." MAL> Instead of discussing code cosmetics we should look into adding MAL> more packagers for e.g. debian and freebsd. These things are MAL> much more important, IMHO. They haven't proven important enough for anyone to do anything about them <0.3 wink>. Jeremy From akuchlin@mems-exchange.org Wed Nov 6 14:47:04 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed Nov 6 14:47:04 2002 Subject: [Distutils] Re: sysconfig.py,1.52,1.53 In-Reply-To: <15817.27244.644338.808306@slothrop.zope.com> References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <15817.25485.566136.459965@slothrop.zope.com> <3DC96801.2000904@lemburg.com> <15817.27244.644338.808306@slothrop.zope.com> Message-ID: <20021106194657.GA2488@ute.mems-exchange.org> On Wed, Nov 06, 2002 at 02:15:56PM -0500, Jeremy Hylton wrote: >I don't think anyone has suggested making changes such that would >prevent people from building distutils packages. I just don't >understand the fear here. Current CVS distutils has new features; for example, the verify_script keyword that just got checked in to bdist_rpm should be fresh in memory. If you use one of these new features in your setup.py file, people running it with an outdated version of Distutils might not be able to install the package. Here's my proposal: * Wrap up the 2.2.2 Distutils as 1.0.3. * Wrap up the 2.3 Distutils as 1.0.4 (or maybe 1.1?) The release-23 branch will have to remain 1.5.2-compatible, in case we need to issue a 1.0.5 release. * After Python 2.3.0 is tagged, we can declare 1.5.2 compatibility dead on the trunk that will lead to Python 2.4, and call it Distutils 1.2 or 2.0. Seem like a plan? I can then get the ball rolling by making a 1.0.3 distribution. >They haven't proven important enough for anyone to do anything about >them <0.3 wink>. At least for a bdist_dpkg, there are technical reasons making it difficult. (I once actually understood those reasons, but have now forgotten them.) Should take another stab at it, though... --amk (www.amk.ca) Nothing ... well, that's something. -- The Doctor, in "Warrior's Gate" From theller@python.net Thu Nov 7 06:57:01 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 7 06:57:01 2002 Subject: [Distutils] setup.py not included in source distribution Message-ID: <4ratpp8e.fsf@ion-tof.com> I came across a strange bug on Win2k, that setup.py is not included in the distribution by default. This only occurrs, when the distribution is built by this command line setup.py sdist and not with python setup.py sdist The problem is that in the first case the MANIFEST file contains this line: C:\sf\distutils\setup.py and this line in the second case: setup.py The cause is that in the first case sys.argv[0] is set to the absolute path 'c:\\sf\\distutils\\setup.py', in the second case it is 'setup.py'. Finally, the sdist command copies it's file list in this way: dest = os.path.join(base_dir, file) self.copy_file(file, dest, link=link) and os.path.join(xxx, yyy) returns yyy when yyy is an absolute path. The workaround is simple: - either use the second form to start the setup script, - or insert 'setup.py' manually in the MANIFEST.in file. Sounds like a bug to me, but I'm not sure how to fix it. Should absolute path names in MANIFEST be allowed or not? Thomas From mal@lemburg.com Thu Nov 7 07:19:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Nov 7 07:19:02 2002 Subject: [Distutils] setup.py not included in source distribution References: <4ratpp8e.fsf@ion-tof.com> Message-ID: <3DCA59EA.7070705@lemburg.com> Thomas Heller wrote: > I came across a strange bug on Win2k, that setup.py > is not included in the distribution by default. > > This only occurrs, when the distribution is built by this command line > > setup.py sdist > > and not with > > python setup.py sdist > > The problem is that in the first case the MANIFEST file contains this line: > C:\sf\distutils\setup.py > and this line in the second case: > setup.py > > The cause is that in the first case sys.argv[0] is set to > the absolute path 'c:\\sf\\distutils\\setup.py', in the second > case it is 'setup.py'. > Finally, the sdist command copies it's file list in this way: > > dest = os.path.join(base_dir, file) > self.copy_file(file, dest, link=link) > > and os.path.join(xxx, yyy) returns yyy when yyy is an absolute path. > > The workaround is simple: > - either use the second form to start the setup script, > - or insert 'setup.py' manually in the MANIFEST.in file. > > Sounds like a bug to me, but I'm not sure how to fix it. > Should absolute path names in MANIFEST be allowed or not? I think that would not be very useful... files in MANIFEST should always be relative to the source distribution directory which is usually the location of the setup.py file. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From theller@python.net Thu Nov 7 07:42:01 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 7 07:42:01 2002 Subject: [Distutils] Re: setup.py not included in source distribution References: <4ratpp8e.fsf@ion-tof.com> <3DCA59EA.7070705@lemburg.com> Message-ID: > > Should absolute path names in MANIFEST be allowed or not? > > I think that would not be very useful... files in MANIFEST > should always be relative to the source distribution directory > which is usually the location of the setup.py file. In this case I suggest this patch: Index: core.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/core.py,v retrieving revision 1.52 diff -c -r1.52 core.py *** core.py 4 Nov 2002 13:45:15 -0000 1.52 --- core.py 7 Nov 2002 12:31:33 -0000 *************** *** 87,93 **** klass = Distribution if not attrs.has_key('script_name'): ! attrs['script_name'] = sys.argv[0] if not attrs.has_key('script_args'): attrs['script_args'] = sys.argv[1:] --- 87,93 ---- klass = Distribution if not attrs.has_key('script_name'): ! attrs['script_name'] = os.path.basename(sys.argv[0]) if not attrs.has_key('script_args'): attrs['script_args'] = sys.argv[1:] From mal@lemburg.com Thu Nov 7 07:46:15 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Nov 7 07:46:15 2002 Subject: [Distutils] Re: setup.py not included in source distribution References: <4ratpp8e.fsf@ion-tof.com> <3DCA59EA.7070705@lemburg.com> Message-ID: <3DCA6029.2030607@lemburg.com> Thomas Heller wrote: >>>Should absolute path names in MANIFEST be allowed or not? >> >>I think that would not be very useful... files in MANIFEST >>should always be relative to the source distribution directory >>which is usually the location of the setup.py file. > > > In this case I suggest this patch: +1 > Index: core.py > =================================================================== > RCS file: /cvsroot/python/distutils/distutils/core.py,v > retrieving revision 1.52 > diff -c -r1.52 core.py > *** core.py 4 Nov 2002 13:45:15 -0000 1.52 > --- core.py 7 Nov 2002 12:31:33 -0000 > *************** > *** 87,93 **** > klass = Distribution > > if not attrs.has_key('script_name'): > ! attrs['script_name'] = sys.argv[0] > if not attrs.has_key('script_args'): > attrs['script_args'] = sys.argv[1:] > > --- 87,93 ---- > klass = Distribution > > if not attrs.has_key('script_name'): > ! attrs['script_name'] = os.path.basename(sys.argv[0]) > if not attrs.has_key('script_args'): > attrs['script_args'] = sys.argv[1:] > > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Mon Nov 11 04:09:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Nov 11 04:09:02 2002 Subject: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53 References: <20021105205040.GA25678@ute.mems-exchange.org> <15816.12364.168272.536845@slothrop.zope.com> <3DC94FF0.4050902@lemburg.com> <2mbs52pn2d.fsf@starship.python.net> <15817.25485.566136.459965@slothrop.zope.com> <3DC96801.2000904@lemburg.com> <15817.27244.644338.808306@slothrop.zope.com> Message-ID: <3DCF7334.5020309@lemburg.com> Jeremy Hylton wrote: >>>>>>"MAL" == mal writes: > > > >> Python 1.5.2 users have been running with distutils 1.0.2 for > >> about a year and a half now. We haven't heard any complaints > >> from them about the lack of releases for 1.5.2. > > MAL> Maybe that's because package developers have tried to keep > MAL> 1.5.2 compatibility by adding bug fixes to their setup.pys ?! > MAL> I know that I've done this in the past. > > Examples, please. I don't maintain any software that is intended to > run with 1.5.2, so I can't quite imagine what you mean. Here's one: # We set these here, since distutils 1.0.2 introduced a # new incompatible way to process .define and .undef if build_ext.define: #print repr(build_ext.define) if type(build_ext.define) is types.StringType: # distutils < 1.0.2 needs this: l = string.split(build_ext.define, ',') build_ext.define = map(lambda symbol: (symbol, '1'), l) build_ext.define = build_ext.define + define else: build_ext.define = define > >> I believe the last release was good enough for 1.5.2. If someone > >> can live with all the bugs and out-of-date stuff in 1.5.2, they > >> can live with a slightly out-of-date distutils, too. > > MAL> If they won't be able to compile distutils packages anymore, > MAL> they certainly won't feel good about it. > > I don't think anyone has suggested making changes such that would > prevent people from building distutils packages. I just don't > understand the fear here. I am talking about users who want to build from source. Your changes, even though just cosmetic, prevent compatibility with Python 1.5.2, so these users will no longer have a chance to update to the latest distutils version. As a result, packagers who want to maintain Python 1.5.2 compatibility will have to start maintaining setup.pys for various distutils versions out there and that's a pain (it already is a pain having to maintain this compatibility for the many Python versions out there). > >> It's a pain in the neck to hack on distutils and be careful to > >> avoid accidentally adding code that won't work with 1.5.2. > > MAL> Huh ? Avoiding string methods isn't all that hard. > > In large software projects like Zope and Mailman, people have > repeatedly run into problems with Python version compatibility. There > are lots of differences between 1.5.2 and 2.2.2, and it is easy to use > a new feature without thinking "I'm using a new feature." We have PEPs for this: http://www.python.org/peps/pep-0291.html http://www.python.org/peps/pep-0290.html It's really not that hard to not use the latest features in coding Python. None of the new hip features are necessary for distutils' application scope. > MAL> Instead of discussing code cosmetics we should look into adding > MAL> more packagers for e.g. debian and freebsd. These things are > MAL> much more important, IMHO. > > They haven't proven important enough for anyone to do anything about > them <0.3 wink>. That is not entirely true. There was an effort to standarize binary packagers and add more support for Solaris and HP-UX. Unfortunately, we had to pull the support from CVS due to copyright issues. I am repeating myself here, but I still don't understand where the motivation to break distutils on Python 1.5.2 stems from. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From rgroenenberg@atsautomation.com Tue Nov 12 09:25:05 2002 From: rgroenenberg@atsautomation.com (Groenenberg, Ron) Date: Tue Nov 12 09:25:05 2002 Subject: [Distutils] ccpython.cc compile problem Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28A57.81109290 Content-Type: text/plain; charset="iso-8859-1" (As this is my first post/mail, please advise if I've picked the wrong SIG for this issue.) My platform is qnx4.24 with watcom 10.6. The v2.2.2 configure files are dated Oct 10 11:26. Configure was done like this: configure --verbose --without-gcc --with-libm="" --with-cxx=cc When gmake was attempted, compiling Modules/ccpython.cc stopped due to this error: //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Error! E415: (col 66) type cannot be defined or declared in a return type //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col 66) included from //5/tmp/py/r on/Python-2.2.2/Include/Python.h(110) //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col 66) included from //5//tmp/py/ ron/Python-2.2.2/Modules/ccpython.cc(4) //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(65): Error! E415: (col 68) type cannot be defined or declared in a return type cc: /usr/watcom/10.6/bin/wpp386 exited 2 gmake: *** [Modules/ccpython.o] Error 2 When I started to workaround this by inserting more include references (such as node.h, compile.h, symtable.h), I soon had a circular reference lock (only splitting headers would appear to resolve that). Any constructive suggestions ? Ron Groenenberg (Many thanks to all the volunteers supporting this.) ------_=_NextPart_001_01C28A57.81109290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(As this is my first post/mail, please advise if = I've picked the wrong SIG for this issue.)

 

My platform is qnx4.24 with watcom 10.6.

The v2.2.2 configure files are dated Oct 10 = 11:26.<= /p>

 

Configure was done like = this:

configure --verbose --without-gcc --with-libm=3D"" --with-cxx=3Dcc

 

When gmake was = attempted, compiling Modules/ccpython.cc stopped due = to this error:

 

//5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Error! E415: (col 66) type cannot be = defined or

=A0declared in a return type

//5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col 66) included from = //5/tmp/py/r

on/Python-2.2.2/Include/Python.h(110)

//5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col 66) included from = //5//tmp/py/

ron/Python-2.2.2/Modules/ccpython.cc(4)

//5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(65): Error! E415: (col 68) type cannot be = defined or

=A0declared in a return type

cc: /usr/watcom/10.6/bin/wpp386 exited = 2

gmake<= /span>: *** [Modules/ccpython.o] Error = 2

 

When I started to workaround this by inserting more = include references (such as node.h, compile.h, symtable.h), I soon had a circular = reference lock (only splitting headers would appear to resolve = that).

 

Any constructive suggestions = ?

 

Ron Groenenberg

 

(Many thanks to all the = volunteers supporting this.)

------_=_NextPart_001_01C28A57.81109290-- From mal@lemburg.com Tue Nov 12 09:48:19 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Nov 12 09:48:19 2002 Subject: [Distutils] ccpython.cc compile problem References: Message-ID: <3DD1146E.5030709@lemburg.com> Groenenberg, Ron wrote: > (As this is my first post/mail, please advise if I've picked the wrong > SIG for this issue.) This sound like a Python problem more than a distutils one (Python uses distutils to build its standard extensions, so you're not entirely wrong here :-). Please post this report to the SourceForge bug tracker. > My platform is qnx4.24 with watcom 10.6. > > The v2.2.2 configure files are dated Oct 10 11:26. > > > > Configure was done like this: > > configure --verbose --without-gcc --with-libm="" --with-cxx=cc > > > > When gmake was attempted, compiling Modules/ccpython.cc stopped due to > this error: > > > > //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Error! E415: (col > 66) type cannot be defined or > > declared in a return type > > //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col > 66) included from //5/tmp/py/r > > on/Python-2.2.2/Include/Python.h(110) > > //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(45): Note! N393: (col > 66) included from //5//tmp/py/ > > ron/Python-2.2.2/Modules/ccpython.cc(4) > > //5/tmp/py/ron/Python-2.2.2/Include/pythonrun.h(65): Error! E415: (col > 68) type cannot be defined or > > declared in a return type Looks as if the compiler doesn't like the use of "struct _somename *" as return type. Try adding typedefs for these in pythonrun.c. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From amk@amk.ca Wed Nov 13 17:01:32 2002 From: amk@amk.ca (A.M. Kuchling) Date: Wed Nov 13 17:01:32 2002 Subject: [Distutils] Killing off bdist_dumb Message-ID: <200211132230.gADMUv205719@nyman.amk.ca> [CC'ed to python-dev, distutils-sig; followups to distutils-sig] In the commentary attached to bug #410541, I suggest removing the bdist_dumb command, because no interesting platforms actually install from zip files. Are there any platforms Python supports, such as Slackware, BeOS, AtheOS, or whatever, where the convention is to do binary installations from .zip files? Any objections to killing bdist_dumb? --amk (www.amk.ca) ROSALIND: My pride fell with my fortune. -- _As You Like It_, I, ii From guido@python.org Wed Nov 13 17:05:11 2002 From: guido@python.org (Guido van Rossum) Date: Wed Nov 13 17:05:11 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: Your message of "Wed, 13 Nov 2002 17:30:57 EST." <200211132230.gADMUv205719@nyman.amk.ca> References: <200211132230.gADMUv205719@nyman.amk.ca> Message-ID: <200211132203.gADM3et07324@odiug.zope.com> > In the commentary attached to bug #410541, I suggest removing the > bdist_dumb command, because no interesting platforms actually install > from zip files. > > Are there any platforms Python supports, such as Slackware, BeOS, > AtheOS, or whatever, where the convention is to do binary > installations from .zip files? Any objections to killing bdist_dumb? Aren't zipfiles used as el-cheapo installers on Windows? I've seen plenty of stuff that was distributed as a simple zipfile, with instructions "unpack ". --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@v.loewis.de Wed Nov 13 17:16:12 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Wed Nov 13 17:16:12 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <200211132203.gADM3et07324@odiug.zope.com> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> Message-ID: Guido van Rossum writes: > Aren't zipfiles used as el-cheapo installers on Windows? I've seen > plenty of stuff that was distributed as a simple zipfile, with > instructions "unpack ". Sure, but on Windows, you have bdist_wininst, which isn't any more difficult to use, and far superior. People building distutils packages for Windows appreciate the fancy-without-efforts installer (I'm one of those people myself); I would never consider using bdist_dumb on Windows. In fact, I thought it was meant for systems like Solaris, where the native packaging is not supported. Of course, on Solaris, I would expect to get a .tar.gz, not a .zip. So even though I do use binutils binary packages, I would not suffer from losing bdist_dumb, and I can't imagine anybody who would. Regards, Martin From guido@python.org Wed Nov 13 17:25:38 2002 From: guido@python.org (Guido van Rossum) Date: Wed Nov 13 17:25:38 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: Your message of "13 Nov 2002 23:14:53 +0100." References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> Message-ID: <200211132224.gADMOEG07559@odiug.zope.com> > > Aren't zipfiles used as el-cheapo installers on Windows? I've seen > > plenty of stuff that was distributed as a simple zipfile, with > > instructions "unpack ". > > Sure, but on Windows, you have bdist_wininst, which isn't any more > difficult to use, and far superior. People building distutils packages > for Windows appreciate the fancy-without-efforts installer (I'm one of > those people myself); I would never consider using bdist_dumb on > Windows. > > In fact, I thought it was meant for systems like Solaris, where the > native packaging is not supported. Of course, on Solaris, I would > expect to get a .tar.gz, not a .zip. > > So even though I do use binutils binary packages, I would not suffer > from losing bdist_dumb, and I can't imagine anybody who would. OK, but bdist_wininst feels fragile (especially when I see checkins of a pile of binary gunk each time something has changed). Zip files are a lowest common denominator. Why do you want to lose bdist_dumb? --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@v.loewis.de Wed Nov 13 17:38:09 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Wed Nov 13 17:38:09 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <200211132224.gADMOEG07559@odiug.zope.com> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> Message-ID: Guido van Rossum writes: > OK, but bdist_wininst feels fragile (especially when I see checkins of > a pile of binary gunk each time something has changed). Zip files are > a lowest common denominator. That was my impression also, but I regained trust when I understood that we actually do have the source for those binaries :-) see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/misc/install.c?annotate=1.22 > Why do you want to lose bdist_dumb? I don't want to lose it, but I wouldn't mind losing it if it simplifies something. I guess that makes it +0. Regards, Martin From DavidA@ActiveState.com Wed Nov 13 17:40:06 2002 From: DavidA@ActiveState.com (David Ascher) Date: Wed Nov 13 17:40:06 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <200211132230.gADMUv205719@nyman.amk.ca> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> Message-ID: <3DD2D467.2030405@ActiveState.com> Guido van Rossum wrote: > >>Aren't zipfiles used as el-cheapo installers on Windows? I've seen > >>plenty of stuff that was distributed as a simple zipfile, with > >>instructions "unpack ". > > > >Sure, but on Windows, you have bdist_wininst, which isn't any more > >difficult to use, and far superior. People building distutils packages > >for Windows appreciate the fancy-without-efforts installer (I'm one of > >those people myself); I would never consider using bdist_dumb on > >Windows. > > > >In fact, I thought it was meant for systems like Solaris, where the > >native packaging is not supported. Of course, on Solaris, I would > >expect to get a .tar.gz, not a .zip. > > > >So even though I do use binutils binary packages, I would not suffer > >from losing bdist_dumb, and I can't imagine anybody who would. > > > OK, but bdist_wininst feels fragile (especially when I see checkins of > a pile of binary gunk each time something has changed). Zip files are > a lowest common denominator. Speaking of which -- I asked someone (can't remember who =) to check the source to that binary junk in the tree somewhere. Did that happen? (my cvs tree here is out of date and I'm getting timeouts from sf, or I'd check). From martin@v.loewis.de Wed Nov 13 18:07:10 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Wed Nov 13 18:07:10 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <3DD2D467.2030405@ActiveState.com> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> <3DD2D467.2030405@ActiveState.com> Message-ID: David Ascher writes: > Speaking of which -- I asked someone (can't remember who =) to check > the source to that binary junk in the tree somewhere. Did that > happen? (my cvs tree here is out of date and I'm getting timeouts from > sf, or I'd check). It's in the distutils CVS, and it always was. Regards, Martin From Andrew.MacIntyre@aba.gov.au Wed Nov 13 18:20:02 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Wed Nov 13 18:20:02 2002 Subject: [Distutils] Killing off bdist_dumb Message-ID: At the moment I use ZIP archives for the OS/2 EMX port, but I don't use bdist_dumb - I remember trying to use it, but can't remember why I stopped trying. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- > -----Original Message----- > From: A.M. Kuchling [mailto:akuchlin@mems-exchange.org] > Sent: Thursday, 14 November 2002 9:31 AM > To: distutils-sig@python.org > Cc: python-dev@python.org > Subject: [Distutils] Killing off bdist_dumb > > > [CC'ed to python-dev, distutils-sig; followups to distutils-sig] > > In the commentary attached to bug #410541, I suggest removing the > bdist_dumb command, because no interesting platforms actually install > from zip files. > > Are there any platforms Python supports, such as Slackware, BeOS, > AtheOS, or whatever, where the convention is to do binary > installations from .zip files? Any objections to killing bdist_dumb? > > --amk > (www.amk.ca) > ROSALIND: My pride fell with my fortune. > -- _As You Like It_, I, ii > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > From A.M.Kuchling Wed Nov 13 20:19:08 2002 From: A.M.Kuchling (A.M.Kuchling) Date: Wed Nov 13 20:19:08 2002 Subject: [Distutils] Killing off bdist_dumb In-Reply-To: <200211132224.gADMOEG07559@odiug.zope.com> Message-ID: <80E979E0-F76E-11D6-ACEF-000393B6F06C@amk.ca> On Wednesday, November 13, 2002, at 05:24 PM, Guido van Rossum wrote: > Why do you want to lose bdist_dumb? Bug #410541 is that the .zip archive created by bdist_dumb is useless because it contains filenames relative to the root directory. Because Python can be installed anywhere on Windows, the .zip files are therefore useless for Windows installation. They might be usable on Unix platforms, as long as you're sure about whether Python is in /usr/ or /usr/local, and if tying it to a single version is OK (because the path will be /usr/lib/pythonX.Y/site-packages). This could be fixed by making it possible to use relative paths, of course, so you'd have to unpack the resulting .zip in site-packages, but if no one uses .zip files for this purpose, why bother? If bdist_wininst wasn't around, then bdist_dumb would be the only way to install on Windows, and clearly this would have to fixed. With bdist_wininst, I don't know if anyone cares. On Unix bdist_dumb also doesn't handle scripts, apparently. Andrew MacIntyre's use of .zip files on OS/2 may save bdist_dumb, though. Andrew, was the use of full paths the problem that kept you from using it? The options are: 1) leave it as-is, broken and useless. (The current state; this seems pointless.) 2) fix it 3) rip it out --amk From Andrew.MacIntyre@aba.gov.au Wed Nov 13 20:46:13 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Wed Nov 13 20:46:13 2002 Subject: [Distutils] Killing off bdist_dumb Message-ID: > Andrew, was the use of full paths the problem that kept you > from using > it? It wouldn't have helped, but I can't recall the details. I'll have to dig into this, as it would be useful to avoid the manual packaging I do at the moment (not that that's a great deal). > The options are: > 1) leave it as-is, broken and useless. (The current state; this > seems pointless.) > 2) fix it > 3) rip it out I agree that 1) is pointless. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From mal@lemburg.com Thu Nov 14 12:43:56 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu Nov 14 12:43:56 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <80E979E0-F76E-11D6-ACEF-000393B6F06C@amk.ca> Message-ID: <3DD35EB0.5010109@lemburg.com> A.M. Kuchling wrote: > On Wednesday, November 13, 2002, at 05:24 PM, Guido van Rossum wrote: > >> Why do you want to lose bdist_dumb? > > Bug #410541 is that the .zip archive created by bdist_dumb is useless > because it contains filenames relative to the root directory. Because > Python can > be installed anywhere on Windows, the .zip files are therefore useless > for Windows installation. They might be usable on Unix platforms, as > long as > you're sure about whether Python is in /usr/ or /usr/local, and if tying > it to a > single version is OK (because the path will be > /usr/lib/pythonX.Y/site-packages). You are forgetting the the power of distutils lies in the ability to subclass these commands, e.g. I use the following to create Zope product packages: class mx_bdist_zope(bdist_dumb): """ Build binary Zope product distribution. """ def finalize_options (self): # Default to ZIP as format on all platforms if self.format is None: self.format = 'zip' bdist_dumb.finalize_options(self) # Hack to reuse bdist_dumb for our purposes; .run() calls # reinitialize_command() with 'install' as command. def reinitialize_command(self, command, reinit_subcommands=0): cmdobj = bdist_dumb.reinitialize_command(self, command, reinit_subcommands) if command == 'install': cmdobj.install_lib = 'lib/python' cmdobj.install_data = 'lib/python' return cmdobj > This could be fixed by making it possible to use relative paths, of course, > so you'd have to unpack the resulting .zip in site-packages, but if no > one uses .zip files for this purpose, why bother? bdist_dumb is useful on other platforms as well. The fact that it basically zips up a binary installation tree is very handy when you are targetting non-installer platforms or when you want to deploy to custom Python installations. > If bdist_wininst wasn't around, then bdist_dumb would be the only way to > install on Windows, and clearly this would have to fixed. With > bdist_wininst, > I don't know if anyone cares. On Unix bdist_dumb also doesn't handle > scripts, apparently. > > Andrew MacIntyre's use of .zip files on OS/2 may save bdist_dumb, though. > Andrew, was the use of full paths the problem that kept you from using it? > > The options are: > 1) leave it as-is, broken and useless. (The current state; this seems > pointless.) > 2) fix it I all you want is to have the ability to make the paths relative, I suggest you add an option for this to the command. > 3) rip it out You can't rip out code that's currently in use without providing at least some kind of alternative. I also don't see any gain from such an approach. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From theller@python.net Thu Nov 14 13:17:56 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 14 13:17:56 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> Message-ID: <3cq4xnjw.fsf@python.net> martin@v.loewis.de (Martin v. Loewis) writes: > Guido van Rossum writes: > > > OK, but bdist_wininst feels fragile (especially when I see checkins of > > a pile of binary gunk each time something has changed). Zip files are > > a lowest common denominator. > > That was my impression also, but I regained trust when I understood > that we actually do have the source for those binaries :-) see > I have already explained several times where the source for bdist_wininst lives, I wont do it again (unless someone needs it). Maybe it could be moved over to the main python module someday. Concerning the 'pile of binary junk' you see on the checkins list each time it has to be recompiled (the bdist_wininst.py module contains the windows exe stub compressed and base64-encoded literally in a large string): This was a design decision which could (and can) be questioned. The checkin messages are one side, the other side is this: it avoids having a binary file (wininst.exe), which only can be created on windows, in the CVS repository and in the distribution. bdist_wininst installers *can* also be created on other systems as long as they only contain pure Python code - although I've never heard of someone actually doing this. So, should the bdist_wininst source code be moved into the python tree, maybe somewhere into PC, and the MSVC .dsw file extended to build the thing, and wininst.exe as binary file go into the distutils directory? Even if this would be done, I'd suggest to wait after the separate distutils release which we have planned on distutils-sig. Thomas From guido@python.org Thu Nov 14 13:19:01 2002 From: guido@python.org (Guido van Rossum) Date: Thu Nov 14 13:19:01 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: Your message of "14 Nov 2002 14:56:19 +0100." <3cq4xnjw.fsf@python.net> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> <3cq4xnjw.fsf@python.net> Message-ID: <200211141400.gAEE0iL29815@pcp02138704pcs.reston01.va.comcast.net> > I have already explained several times where the source for > bdist_wininst lives, I wont do it again (unless someone needs it). > Maybe it could be moved over to the main python module someday. > > Concerning the 'pile of binary junk' you see on the checkins list > each time it has to be recompiled (the bdist_wininst.py module contains > the windows exe stub compressed and base64-encoded literally in a large > string): > > This was a design decision which could (and can) be questioned. The > checkin messages are one side, the other side is this: it avoids > having a binary file (wininst.exe), which only can be created on > windows, in the CVS repository and in the distribution. > > bdist_wininst installers *can* also be created on other systems > as long as they only contain pure Python code - although I've never > heard of someone actually doing this. > > So, should the bdist_wininst source code be moved into the python > tree, maybe somewhere into PC, and the MSVC .dsw file extended to > build the thing, and wininst.exe as binary file go into the distutils > directory? Even if this would be done, I'd suggest to wait after the > separate distutils release which we have planned on distutils-sig. +1 --Guido van Rossum (home page: http://www.python.org/~guido/) From theller@python.net Thu Nov 14 13:23:16 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 14 13:23:16 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <200211141400.gAEE0iL29815@pcp02138704pcs.reston01.va.comcast.net> References: <200211132230.gADMUv205719@nyman.amk.ca> <200211132203.gADM3et07324@odiug.zope.com> <200211132224.gADMOEG07559@odiug.zope.com> <3cq4xnjw.fsf@python.net> <200211141400.gAEE0iL29815@pcp02138704pcs.reston01.va.comcast.net> Message-ID: > > So, should the bdist_wininst source code be moved into the python > > tree, maybe somewhere into PC, and the MSVC .dsw file extended to > > build the thing, and wininst.exe as binary file go into the distutils > > directory? Even if this would be done, I'd suggest to wait after the > > separate distutils release which we have planned on distutils-sig. > > +1 Ok, so I'll enter a bug for this and assign it to me. Thomas From Andrew.MacIntyre@aba.gov.au Thu Nov 14 18:37:01 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Thu Nov 14 18:37:01 2002 Subject: [Distutils] Killing off bdist_dumb Message-ID: > Andrew, was the use of full paths the problem that kept you > from using it? After revisiting some experiments, I can say that full paths was the issue that kept me from using it. While I note MAL's point about sub-classing, that is only useful from the POV of a module author. My POV is that of a 3rd party who wants to build & distribute installable module binaries to accompany a non-PythonLabs Python binary distribution. >From this POV, on the particular platform I'm supporting, what I want is bdist_dumb to default to using paths relative to sys.prefix. I tried to suss out what changes might achieve this, and the simplest option that occurred to me was to move down the extra directory levels when changing directory into the "dumb" directory prior to zipping things up. This is not too bad for OS/2, where the installation structure has always been simple & consistent across releases, but other platforms are more involved. A bdist_dumb option to select between full & relative paths would be Ok. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From mal@lemburg.com Fri Nov 15 03:33:13 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 15 03:33:13 2002 Subject: [Distutils] Killing off bdist_dumb References: Message-ID: <3DD4B0F1.70106@lemburg.com> Andrew MacIntyre wrote: >>Andrew, was the use of full paths the problem that kept you >>from using it? > > > After revisiting some experiments, I can say that full paths was the > issue that kept me from using it. > > While I note MAL's point about sub-classing, that is only useful from > the POV of a module author. You probably mean "packager". The developer isn't necessarily the same person, e.g. a user might want to build from source then redistribute a package in some other way. > My POV is that of a 3rd party who wants to build & distribute installable > module binaries to accompany a non-PythonLabs Python binary distribution. > >>From this POV, on the particular platform I'm supporting, what I want is > bdist_dumb to default to using paths relative to sys.prefix. Please don't change defaults: this only introduces hassles for packagers since they'll have to add multi-version support to their setup.py which only complicates the process. If you want to add new functionality, provide a command option and then use that in your code. If you want to use this as default, place the option into the setup.cfg file. > I tried to suss out what changes might achieve this, and the simplest > option that occurred to me was to move down the extra directory levels > when changing directory into the "dumb" directory prior to zipping > things up. This is not too bad for OS/2, where the installation > structure has always been simple & consistent across releases, but > other platforms are more involved. > > A bdist_dumb option to select between full & relative paths would be > Ok. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From SteffanapGeraintBowen@gwynedd.gov.uk Fri Nov 15 04:01:02 2002 From: SteffanapGeraintBowen@gwynedd.gov.uk (Bowen Steffan ap Geraint GT/IT) Date: Fri Nov 15 04:01:02 2002 Subject: [Distutils] problem running python setup.py Message-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-05c37836-5471-496b-93c5-fa8a7263340e Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28C85.57835900" ------_=_NextPart_001_01C28C85.57835900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been attempting to run python setup.py build in /usr/local/dc/Distutils-1.0.2 and this is the output I get. I would be pleased if you could give me any advice as to what to do to resolve this problem. I am using python version 1.5 on Linux release 6.0 (Hedwig) Kernel 2.2.5-22 on an i586 Error in %s at %d: %s ('setup.cfg', 21, "'[bdist_rpm]\\012'") Error in %s at %d: %s ('setup.cfg', 24, "'doc_files =3D CHANGES.txt\\012'") Traceback (innermost last): File "setup.py", line 13, in ? setup (name =3D "Distutils", File "distutils/core.py", line 110, in setup dist.parse_config_files() File "distutils/dist.py", line 323, in parse_config_files parser.read(filename) File "/usr/lib/python1.5/ConfigParser.py", line 154, in read self.__read(fp) File "/usr/lib/python1.5/ConfigParser.py", line 232, in __read cursect =3D cursect[optname] + '\n ' + value TypeError: expected integer index This is the contents of setup.cfg =20 # # setup.cfg # # the Distutils config file. Just as with the Distutils setup script, this # has the dual purpose of being used to distribute the Distutils and # serving as an example of some of the things you can do with Distutils # config files. Currently, this is only useful for me (assuming I'm the # only person who creates Distutils source and RPM distributions), but you # could add build and installation preferences here, too. (Although those # sorts of things are probably best handled on a site-wide or per-user # basis, rather than in the config file for each module distribution.) # # created 2000/05/31, Greg Ward # # $Id: setup.cfg,v 1.3 2000/06/30 03:45:44 gward Exp $ # =20 [sdist] formats=3Dgztar,zip =20 [bdist_rpm] release =3D 1 packager =3D Greg Ward doc_files =3D CHANGES.txt README.txt USAGE.txt doc/ examples/ =20 changelog =3D * Thu Jun 29 2000 Greg Ward 0.9 - Made myself the packager, since I can now create the RPM on my own =20 * Sun Jun 04 2000 Harry Henry Gebel 0.9pre-1 - Made sure scripts are file names, filled in some help strings, formatted changelog correctly =20 * Wed May 31 2000 Greg Ward 0.8.3pre-1 - Hacked up bdist_rpm.py, moved meta-data into setup.cfg =20 * Thu May 10 2000 Harry Henry Gebel 0.8.2-3 - Added new options to package_data =20 * Tue May 09 2000 Harry Henry Gebel 0.8.2-2 - Include RPM_OPT_FLAGS in distutils =20 * Wed Apr 26 2000 Harry Henry Gebel 0.8.2-1 - First test of bdist_rpm =20 Thank you Steffan. G. Bowen =20 ------_=_NextPart_001_01C28C85.57835900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I have been attempting to run python = setup.py=20 build in  /usr/local/dc/Distutils-1.0.2 = and this=20 is the output I get. I would be = pleased if=20 you could give me any advice as to what to do to resolve this = problem. I am using=20 python version 1.5 on Linux release 6.0 (Hedwig) Kernel 2.2.5-22 = on an=20 i586

Error in = %s at %d:=20 %s ('setup.cfg', 21, "'[bdist_rpm]\\012'")
Error in %s at %d: %s=20 ('setup.cfg', 24, "'doc_files =3D CHANGES.txt\\012'")
Traceback = (innermost=20 last):
  File "setup.py", line 13, in ?
    = setup=20 (name =3D "Distutils",
  File "distutils/core.py", line 110, in=20 setup
    dist.parse_config_files()
  File=20 "distutils/dist.py", line 323, in = parse_config_files
   =20 parser.read(filename)
  File = "/usr/lib/python1.5/ConfigParser.py", line=20 154, in read
    self.__read(fp)
  File=20 "/usr/lib/python1.5/ConfigParser.py", line 232, in = __read
   =20 cursect =3D cursect[optname] + '\n ' + value
TypeError: expected = integer=20 index

This = is the contents=20 of setup.cfg
 
#
# = setup.cfg
#
# the Distutils config file.  Just as with the = Distutils=20 setup script, this
# has the dual purpose of being used to distribute = the=20 Distutils and
# serving as an example of some of the things you can = do with=20 Distutils
# config files.  Currently, this is only useful for me = (assuming I'm the
# only person who creates Distutils source and RPM=20 distributions), but you
# could add build and installation = preferences here,=20 too.  (Although those
# sorts of things are probably best = handled on a=20 site-wide or per-user
# basis, rather than in the config file for = each module=20 distribution.)
#
# created 2000/05/31, Greg Ward
#
# $Id:=20 setup.cfg,v 1.3 2000/06/30 03:45:44 gward Exp $
#
 
[sdist]
formats=3Dgztar,zip
 
[bdist_rpm]
release =3D 1
packager =3D = Greg Ward=20 <gward@python.net>
doc_files = =3D=20 CHANGES.txt
         &nbs= p; =20 README.txt
          = ; =20 USAGE.txt
          =  =20 doc/
           = ;=20 examples/
 
changelog=20 =3D
  * Thu Jun 29 2000 Greg Ward <gward@python.net> 0.9
  = - Made=20 myself the packager, since I can now create the RPM on my=20 own
 
  = * Sun Jun 04=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.9pre-1
  - Made=20 sure scripts are file names, filled in some help strings,=20 formatted
    changelog correctly
 
  = * Wed May 31=20 2000 Greg Ward <gward@python.net>=20 0.8.3pre-1
  - Hacked up bdist_rpm.py, moved meta-data into=20 setup.cfg
 
  = * Thu May 10=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-3
  - Added=20 new options to package_data
 
  = * Tue May 09=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-2
  -=20 Include RPM_OPT_FLAGS in distutils
 
  = * Wed Apr 26=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-1
  - First=20 test of bdist_rpm
 
Thank=20 you
Steffan. G.=20 Bowen
 
=00 ------_=_NextPart_001_01C28C85.57835900-- ------=_NextPartTM-000-05c37836-5471-496b-93c5-fa8a7263340e Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ------------------------------------------------------------- Mae'r e-bost hwn ac unrhyw atodiad iddo yn gyfrinachol ac fe'i bwriedir ar gyfer y sawl a enwir arno yn unig. Gall gynnwys gwybodaeth freintiedig. Os yw wedi eich cyrraedd trwy gamgymeriad ni ellwch ei gopio, ei ddosbarthu na'i ddangos i unrhyw un arall a dylech gysylltu â'r Cyngor ar unwaith. Mae unrhyw gynnwys nad yw'n ymwneud â busnes swyddogol Cyngor Gwynedd yn bersonol i'r awdur ac nid yw'n awdurdodedig gan y Cyngor. ------------------------------------------------------------- This email and any attachments are confidential and intended for the named recipient only. The content may contain privileged information. If it has reached you by mistake, you should not copy, distribute or show the content to anyone but should contact Gwynedd Council at once. Any content that is not pertinent to Gwynedd Council business is personal to the author, and is not necessarily the view of the Council. ------------------------------------------------------------- ------=_NextPartTM-000-05c37836-5471-496b-93c5-fa8a7263340e-- From fredrik@pythonware.com Fri Nov 15 04:56:09 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri Nov 15 04:56:09 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <200211132230.gADMUv205719@nyman.amk.ca> Message-ID: <00cb01c28c8d$221739a0$0900a8c0@spiff> amk wrote: > In the commentary attached to bug #410541, I suggest removing the > bdist_dumb command, because no interesting platforms actually install > from zip files. =20 how is bdist_dumb different from a plain bdist? if you decide to keep it in there, can you at least fix the help text: bdist create a built (binary) distribution bdist_dumb create a "dumb" built distribution bdist_rpm create an RPM distribution bdist_wininst create an executable installer for MS Windows oh, dumb really means "dumb". that's helpful. From mal@lemburg.com Fri Nov 15 05:15:15 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 15 05:15:15 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <200211132230.gADMUv205719@nyman.amk.ca> <00cb01c28c8d$221739a0$0900a8c0@spiff> Message-ID: <3DD4C8B7.3040703@lemburg.com> Fredrik Lundh wrote: > amk wrote: > > >>In the commentary attached to bug #410541, I suggest removing the >>bdist_dumb command, because no interesting platforms actually install >>from zip files. > > > how is bdist_dumb different from a plain bdist? > > if you decide to keep it in there, can you at least fix the > help text: > > bdist create a built (binary) distribution Hmm, I wonder why bdist is mentioned here: it's the base class driving all the other sub-commands. bdist doesn't do anything on its own. > bdist_dumb create a "dumb" built distribution > bdist_rpm create an RPM distribution > bdist_wininst create an executable installer for MS Windows > > oh, dumb really means "dumb". that's helpful. From the doc-string: create a "dumb" built distribution -- i.e., just an archive to be unpacked under $prefix or $exec_prefix. The short info should probably be: create a drop-in installation archive -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From fredrik@pythonware.com Fri Nov 15 07:17:18 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri Nov 15 07:17:18 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <200211132230.gADMUv205719@nyman.amk.ca> <00cb01c28c8d$221739a0$0900a8c0@spiff> <3DD4C8B7.3040703@lemburg.com> Message-ID: <018d01c28ca0$df0073c0$0900a8c0@spiff> mal wrote: > > if you decide to keep it in there, can you at least fix the > > help text: > >=20 > > bdist create a built (binary) distribution >=20 > Hmm, I wonder why bdist is mentioned here: it's the base > class driving all the other sub-commands. bdist doesn't > do anything on its own. have you tried it? on the 2.2 unix install I have here, it builds a tar archive. from what I can tell, it's actually running the same code as bdist_dumb... > From the doc-string: >=20 > create a "dumb" built distribution -- i.e., just an archive > to be unpacked under $prefix or $exec_prefix. which isn't true, obviously, since the archive contains absolute paths... From amk@amk.ca Fri Nov 15 08:48:04 2002 From: amk@amk.ca (A.M. Kuchling) Date: Fri Nov 15 08:48:04 2002 Subject: [Distutils] problem running python setup.py In-Reply-To: ; from SteffanapGeraintBowen@gwynedd.gov.uk on Fri, Nov 15, 2002 at 08:59:44AM -0000 References: Message-ID: <20021115091801.A25041@nyman.amk.ca> On Fri, Nov 15, 2002 at 08:59:44AM -0000, Bowen Steffan ap Geraint GT/IT wrote: >pleased if you could give me any advice as to what to do to resolve this >problem. I am using python version 1.5 on Linux release 6.0 (Hedwig) >Kernel 2.2.5-22 on an i586 I don't know; when I try the setup.cfg with 1.5.2 it works fine, after fixing a few lines that got word-wrapped by your mailer. Note that there are bugfix releases after 1.5, so this bug might have been fixed in Python 1.5.2; you should try upgrading to it, or at least trying the ConfigParser.py file from 1.5.2. > File "/usr/lib/python1.5/ConfigParser.py", line 232, in __read > cursect = cursect[optname] + '\n ' + value >TypeError: expected integer index The error message may imply that cursect is a sequence of some sort, but that section of ConfigParser.py assumes that cursect contains a dictionary. You could debug the problem, starting by putting debugging prints into ConfigParser to find out what cursect is, and working backwards from there. --amk (www.amk.ca) "Ah, yes. Dear Frank. I'm afraid he's had to retire early with a mild touch of insanity." -- Oscar Wilde, in FROM HELL #11 From mal@lemburg.com Fri Nov 15 10:14:09 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 15 10:14:09 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <200211132230.gADMUv205719@nyman.amk.ca> <00cb01c28c8d$221739a0$0900a8c0@spiff> <3DD4C8B7.3040703@lemburg.com> <018d01c28ca0$df0073c0$0900a8c0@spiff> Message-ID: <3DD50EB4.6050000@lemburg.com> Fredrik Lundh wrote: > mal wrote: > > >>>if you decide to keep it in there, can you at least fix the >>>help text: >>> >>> bdist create a built (binary) distribution >> >>Hmm, I wonder why bdist is mentioned here: it's the base >>class driving all the other sub-commands. bdist doesn't >>do anything on its own. > > > have you tried it? No, I read the code... looks like these attributes make bdist_dumb the default sub-command to run when no other command is specified: # This won't do in reality: will need to distinguish RPM-ish Linux, # Debian-ish Linux, Solaris, FreeBSD, ..., Windows, Mac OS. default_format = { 'posix': 'gztar', 'nt': 'zip', 'os2': 'zip', } # And the real information. format_command = { 'rpm': ('bdist_rpm', "RPM distribution"), 'zip': ('bdist_dumb', "ZIP file"), 'gztar': ('bdist_dumb', "gzip'ed tar file"), 'bztar': ('bdist_dumb', "bzip2'ed tar file"), 'ztar': ('bdist_dumb', "compressed tar file"), 'tar': ('bdist_dumb', "tar file"), 'wininst': ('bdist_wininst', "Windows executable installer"), 'zip': ('bdist_dumb', "ZIP file"), #'pkgtool': ('bdist_pkgtool', # "Solaris pkgtool distribution"), #'sdux': ('bdist_sdux', "HP-UX swinstall depot"), } Funny; I would have expected that bdist is a no-op. > on the 2.2 unix install I have here, it builds a tar archive. from what > I can tell, it's actually running the same code as bdist_dumb... > > >> From the doc-string: >> >> create a "dumb" built distribution -- i.e., just an archive >> to be unpacked under $prefix or $exec_prefix. > > > which isn't true, obviously, since the archive contains absolute > paths... Right. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From amk@amk.ca Fri Nov 15 10:43:02 2002 From: amk@amk.ca (Andrew Kuchling) Date: Fri Nov 15 10:43:02 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <3DD50EB4.6050000@lemburg.com> Message-ID: <44185B68-F8B0-11D6-B409-000393B6F06C@amk.ca> On Friday, November 15, 2002, at 10:11 AM, M.-A. Lemburg wrote: > Funny; I would have expected that bdist is a no-op. Presumably Greg's original goal was that running bdist would run the right builder for your platform: bdist_rpm on Red Hat, bdist_wininst on Windows, etc. It would be nice to make that work correctly. (But how can you tell whether a Linux distribution uses RPM or DEB natively?) --amk From theller@python.net Fri Nov 15 10:46:07 2002 From: theller@python.net (Thomas Heller) Date: Fri Nov 15 10:46:07 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <3DD50EB4.6050000@lemburg.com> References: <200211132230.gADMUv205719@nyman.amk.ca> <00cb01c28c8d$221739a0$0900a8c0@spiff> <3DD4C8B7.3040703@lemburg.com> <018d01c28ca0$df0073c0$0900a8c0@spiff> <3DD50EB4.6050000@lemburg.com> Message-ID: > > Funny; I would have expected that bdist is a no-op. > python setup.py bdist --help or python setup.py sdist --help gives also useful info. Also the --help-formats options. Thomas From davida@pobox.com Fri Nov 15 19:16:01 2002 From: davida@pobox.com (David Arnold) Date: Fri Nov 15 19:16:01 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: Your message of "Fri, 15 Nov 2002 10:38:19 CDT." <44185B68-F8B0-11D6-B409-000393B6F06C@amk.ca> Message-ID: <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> -->"Andrew" == Andrew Kuchling writes: Andrew> (But how can you tell whether a Linux distribution uses RPM Andrew> or DEB natively?) checking for the presence of /etc/redhat_release or /etc/debian.version (or whatever their actual spelling is) would give you a good guess. alternatively, checking for the presence of the debian installer tools (dpkg, etc) would tend to indicate a debian system, and if that fails, checking for the rpm binary should do (debian systems can have the rpm binary installed also, but checking for dpkg first should be ok). d From bhoel@web.de Sat Nov 16 16:41:33 2002 From: bhoel@web.de (Berthold =?iso-8859-15?q?H=F6llmann?=) Date: Sat Nov 16 16:41:33 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> References: <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> Message-ID: David Arnold writes: > -->"Andrew" == Andrew Kuchling writes: > > Andrew> (But how can you tell whether a Linux distribution uses RPM > Andrew> or DEB natively?) > > checking for the presence of /etc/redhat_release or > /etc/debian.version (or whatever their actual spelling is) would give > you a good guess. For SuSE this would be /etc/SuSE-release (at least for 8.1). Maybe /etc/issue would provide a nice guess, if it is not changed. > alternatively, checking for the presence of the debian installer tools > (dpkg, etc) would tend to indicate a debian system, and if that fails, > checking for the rpm binary should do (debian systems can have the rpm > binary installed also, but checking for dpkg first should be ok). I'm on a rpm based SuSE 8.1 system: >where dpkg /usr/bin/dpkg >where rpm /bin/rpm so this does not work either. Greetings Berthold -- bhoel@web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad. From Jack.Jansen@oratrix.com Sat Nov 16 19:22:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat Nov 16 19:22:01 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: <44185B68-F8B0-11D6-B409-000393B6F06C@amk.ca> Message-ID: <82FAB371-F9C2-11D6-9BEC-000A27B19B96@oratrix.com> On vrijdag, nov 15, 2002, at 16:38 Europe/Amsterdam, Andrew Kuchling wrote: > On Friday, November 15, 2002, at 10:11 AM, M.-A. Lemburg wrote: >> Funny; I would have expected that bdist is a no-op. > > Presumably Greg's original goal was that running bdist would run > the right builder for your platform: bdist_rpm on Red Hat, > bdist_wininst on Windows, etc. It would be nice to make that work > correctly. Is this a good idea? Wouldn't it lead naive distributors to think that once they've done "setup.py bdist" their work is done without realizing they've left 90% of the world out in the cold? -- - 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 Jack.Jansen@oratrix.com Sat Nov 16 19:42:01 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Sat Nov 16 19:42:01 2002 Subject: [Distutils] I think I need more detail in the build directory Message-ID: <3D10733C-F9C5-11D6-9BEC-000A27B19B96@oratrix.com> Folks, I think I need more details in the filenames (the temp. and lib. ones) in the build directory. On MacOSX there are two ways to build Python: in the traditional unix way (statically linked, prefix is usually /usr or /usr/local) or in the all-singing-all-dancing framework way (dynamically linked with extra bells and whistles, the python installation deep down in /Library/Frameworks/Python.framework/etcetcetc, with a symlink "python" usually in /usr/local/bin). Extension modules for these two Pythons are incompatible, but unfortunately they don't realise that, and things may even sort-of work some of the time. Note that this problem has really existed all along, and on all platforms (try building a module with a refcount-debug python, and then doing a setup install with a non-refcount-debug python for a nasty surprise), but for MacOSX it may now become an end-user problem, since Apple ships Python in Jaguar and this is a static python, but to get access to the MacPython goodies people will download a source distribution and build a framework python. I have an idea on a solution to this, but I'm not sure whether it's feasible (and correct:-): 1. Encode features that make a python interpreter and a module incompatible in PYTHON_API_VERSION. We have about 20 bits left in there. This would however require convincing the core developers. 2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the distutils filenames. Comments? -- - 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 Mon Nov 18 03:36:30 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Nov 18 03:36:30 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb References: <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> Message-ID: <3DD81070.4090903@lemburg.com> David Arnold wrote: > -->"Andrew" == Andrew Kuchling writes: > > Andrew> (But how can you tell whether a Linux distribution uses RPM > Andrew> or DEB natively?) > > checking for the presence of /etc/redhat_release or > /etc/debian.version (or whatever their actual spelling is) would give > you a good guess. > > alternatively, checking for the presence of the debian installer tools > (dpkg, etc) would tend to indicate a debian system, and if that fails, > checking for the rpm binary should do (debian systems can have the rpm > binary installed also, but checking for dpkg first should be ok). I don't think that we really need such guessing. When distributing packages you usually build for a lot of different targets, not just only for the system you are using. I wonder why noone from the debian camp has yet contributed a packager for this platform. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Mon Nov 18 03:47:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Nov 18 03:47:01 2002 Subject: [Distutils] I think I need more detail in the build directory References: <3D10733C-F9C5-11D6-9BEC-000A27B19B96@oratrix.com> Message-ID: <3DD812F7.1080805@lemburg.com> Jack Jansen wrote: > Folks, > I think I need more details in the filenames (the temp. and lib. ones) > in the build directory. > > On MacOSX there are two ways to build Python: in the traditional unix > way (statically linked, prefix is usually /usr or /usr/local) or in the > all-singing-all-dancing framework way (dynamically linked with extra > bells and whistles, the python installation deep down in > /Library/Frameworks/Python.framework/etcetcetc, with a symlink "python" > usually in /usr/local/bin). Extension modules for these two Pythons are > incompatible, but unfortunately they don't realise that, and things may > even sort-of work some of the time. > > Note that this problem has really existed all along, and on all > platforms (try building a module with a refcount-debug python, and then > doing a setup install with a non-refcount-debug python for a nasty > surprise), but for MacOSX it may now become an end-user problem, since > Apple ships Python in Jaguar and this is a static python, but to get > access to the MacPython goodies people will download a source > distribution and build a framework python. > > I have an idea on a solution to this, but I'm not sure whether it's > feasible (and correct:-): > 1. Encode features that make a python interpreter and a module > incompatible in PYTHON_API_VERSION. We have about 20 bits left in there. > This would however require convincing the core developers. > 2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the > distutils filenames. Rather than trying to be clever here, why not add an option to distutils to let the packager add an arbitrary directory name extension to the build dir ?! That way, the developer can add whatever information is needed to the build dir name. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From davida@pobox.com Mon Nov 18 09:21:01 2002 From: davida@pobox.com (David Arnold) Date: Mon Nov 18 09:21:01 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: Your message of "Sun, 17 Nov 2002 22:56:00 BST." <3DD81070.4090903@lemburg.com> Message-ID: <200211181343.gAIDh7k07232@xevious.dstc.monash.edu.au> -->"MAL" == M -A Lemburg writes: MAL> I don't think that we really need such guessing. When MAL> distributing packages you usually build for a lot of different MAL> targets, not just only for the system you are using. right. MAL> I wonder why noone from the debian camp has yet contributed a MAL> packager for this platform. i've had a look at doing this, but it's a little painful. it's lurking down in the middle of my todo list, and i wouldn't expect cycles to be allocated to it unless priorities change :-( d From Jack.Jansen@oratrix.com Mon Nov 18 09:38:02 2002 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Mon Nov 18 09:38:02 2002 Subject: [Distutils] I think I need more detail in the build directory In-Reply-To: <3DD812F7.1080805@lemburg.com> Message-ID: <3AF0D0E4-FB02-11D6-9B18-000A27B19B96@oratrix.com> On zondag, nov 17, 2002, at 23:06 Europe/Amsterdam, M.-A. Lemburg wrote: > Jack Jansen wrote: >> Folks, >> I think I need more details in the filenames (the temp. and lib. >> ones) in the build directory. >> On MacOSX there are two ways to build Python: in the traditional unix >> way (statically linked, prefix is usually /usr or /usr/local) or in >> the all-singing-all-dancing framework way (dynamically linked with >> extra bells and whistles, the python installation deep down in >> /Library/Frameworks/Python.framework/etcetcetc, with a symlink >> "python" usually in /usr/local/bin). Extension modules for these two >> Pythons are incompatible, but unfortunately they don't realise that, >> and things may even sort-of work some of the time. >> Note that this problem has really existed all along, and on all >> platforms (try building a module with a refcount-debug python, and >> then doing a setup install with a non-refcount-debug python for a >> nasty surprise), but for MacOSX it may now become an end-user >> problem, since Apple ships Python in Jaguar and this is a static >> python, but to get access to the MacPython goodies people will >> download a source distribution and build a framework python. >> I have an idea on a solution to this, but I'm not sure whether it's >> feasible (and correct:-): >> 1. Encode features that make a python interpreter and a module >> incompatible in PYTHON_API_VERSION. We have about 20 bits left in >> there. This would however require convincing the core developers. >> 2. Use PYTHON_API_VERSION in stead of the "2.3" style version in the >> distutils filenames. > > Rather than trying to be clever here, why not add an option to > distutils to let the packager add an arbitrary directory name > extension to the build dir ?! You miss the point. The problem is not with specific packages, the problem is general. The directory names within "build" are supposed to be encoded in such a way that you can do "python setup.py build" with two different pythons and the files created for the two pythons won't conflict. As it is now this works fine if the two pythons differ in version number or if the two pythons are for different platforms. It does not work, however, if the two pythons are the same version and run on the same platform, but differ in another incompatible way. -- - 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 Mon Nov 18 09:50:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Nov 18 09:50:02 2002 Subject: [Distutils] I think I need more detail in the build directory References: <3AF0D0E4-FB02-11D6-9B18-000A27B19B96@oratrix.com> Message-ID: <3DD8FD98.3020807@lemburg.com> Jack Jansen wrote: > > On zondag, nov 17, 2002, at 23:06 Europe/Amsterdam, M.-A. Lemburg wrote: > >>> Rather than trying to be clever here, why not add an option to >> distutils to let the packager add an arbitrary directory name >> extension to the build dir ?! > > > You miss the point. The problem is not with specific packages, the > problem is general. The directory names within "build" are supposed to > be encoded in such a way that you can do "python setup.py build" with > two different pythons and the files created for the two pythons won't > conflict. > > As it is now this works fine if the two pythons differ in version number > or if the two pythons are for different platforms. It does not work, > however, if the two pythons are the same version and run on the same > platform, but differ in another incompatible way. And that's what you could put to work by specifying an option which let's you introduce extra dir-name components, e.g. --build-dir-addon pydebug-nounicode could generate: temp.linux-i686-2.1.pydebug-nounicode/ as temporary build dir. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From akuchlin@mems-exchange.org Mon Nov 18 09:52:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Nov 18 09:52:01 2002 Subject: [Distutils] I think I need more detail in the build directory In-Reply-To: <3AF0D0E4-FB02-11D6-9B18-000A27B19B96@oratrix.com> References: <3DD812F7.1080805@lemburg.com> <3AF0D0E4-FB02-11D6-9B18-000A27B19B96@oratrix.com> Message-ID: <20021118145151.GA17246@ute.mems-exchange.org> On Mon, Nov 18, 2002 at 03:30:05PM +0100, Jack Jansen wrote: >As it is now this works fine if the two pythons differ in version >number or if the two pythons are for different platforms. It does not >work, however, if the two pythons are the same version and run on the >same platform, but differ in another incompatible way. I'd have no objection to using API_VERSION instead of the Python version, but it only became available to Python code in 2.3CVS, so there'd be no way to get it in Apple's Python. Similar problems apply to tracing/debugging; can Python code determine what the options are for the interpreter it's running in? --amk (www.amk.ca) MALCOLM: Angels are bright still, though the brightest fell. -- _Macbeth_, IV, iii From mats@laplaza.org Mon Nov 18 15:44:11 2002 From: mats@laplaza.org (Mats Wichmann) Date: Mon Nov 18 15:44:11 2002 Subject: [Distutils] Re: [Python-Dev] Killing off bdist_dumb In-Reply-To: References: <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> <200211152339.gAFNdDk28046@xevious.dstc.monash.edu.au> Message-ID: <5.1.0.14.1.20021118133919.0279b2c0@204.151.72.2> >> Andrew> (But how can you tell whether a Linux distribution uses RPM >> Andrew> or DEB natively?) >> >> checking for the presence of /etc/redhat_release or >> /etc/debian.version (or whatever their actual spelling is) would give >> you a good guess. > >For SuSE this would be /etc/SuSE-release (at least for 8.1). and /etc/Mandrake-release, and /etc/UnitedLinux-release, etc. This looks like a slippery slope to venture down... From SteffanapGeraintBowen@gwynedd.gov.uk Tue Nov 19 04:46:00 2002 From: SteffanapGeraintBowen@gwynedd.gov.uk (Bowen Steffan ap Geraint GT/IT) Date: Tue Nov 19 04:46:00 2002 Subject: [Distutils] problem running python setup.py Message-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-5a53145d-91f0-4b39-9ec6-e9aec53a5e80 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28FB0.32314120" ------_=_NextPart_001_01C28FB0.32314120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been attempting to run python setup.py build in /usr/local/dc/Distutils-1.0.2 and this is the output I get. I would be pleased if you could give me any advice as to what to do to resolve this problem. I am using python version 1.5 on Linux release 6.0 (Hedwig) Kernel 2.2.5-22 on an i586 Error in %s at %d: %s ('setup.cfg', 21, "'[bdist_rpm]\\012'") Error in %s at %d: %s ('setup.cfg', 24, "'doc_files =3D CHANGES.txt\\012'") Traceback (innermost last): File "setup.py", line 13, in ? setup (name =3D "Distutils", File "distutils/core.py", line 110, in setup dist.parse_config_files() File "distutils/dist.py", line 323, in parse_config_files parser.read(filename) File "/usr/lib/python1.5/ConfigParser.py", line 154, in read self.__read(fp) File "/usr/lib/python1.5/ConfigParser.py", line 232, in __read cursect =3D cursect[optname] + '\n ' + value TypeError: expected integer index This is the contents of setup.cfg =20 # # setup.cfg # # the Distutils config file. Just as with the Distutils setup script, this # has the dual purpose of being used to distribute the Distutils and # serving as an example of some of the things you can do with Distutils # config files. Currently, this is only useful for me (assuming I'm the # only person who creates Distutils source and RPM distributions), but you # could add build and installation preferences here, too. (Although those # sorts of things are probably best handled on a site-wide or per-user # basis, rather than in the config file for each module distribution.) # # created 2000/05/31, Greg Ward # # $Id: setup.cfg,v 1.3 2000/06/30 03:45:44 gward Exp $ # =20 [sdist] formats=3Dgztar,zip =20 [bdist_rpm] release =3D 1 packager =3D Greg Ward doc_files =3D CHANGES.txt README.txt USAGE.txt doc/ examples/ =20 changelog =3D * Thu Jun 29 2000 Greg Ward 0.9 - Made myself the packager, since I can now create the RPM on my own =20 * Sun Jun 04 2000 Harry Henry Gebel 0.9pre-1 - Made sure scripts are file names, filled in some help strings, formatted changelog correctly =20 * Wed May 31 2000 Greg Ward 0.8.3pre-1 - Hacked up bdist_rpm.py, moved meta-data into setup.cfg =20 * Thu May 10 2000 Harry Henry Gebel 0.8.2-3 - Added new options to package_data =20 * Tue May 09 2000 Harry Henry Gebel 0.8.2-2 - Include RPM_OPT_FLAGS in distutils =20 * Wed Apr 26 2000 Harry Henry Gebel 0.8.2-1 - First test of bdist_rpm =20 Thank you Steffan. G. Bowen =20 ------_=_NextPart_001_01C28FB0.32314120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

I have been attempting to run python = setup.py=20 build in  /usr/local/dc/Distutils-1.0.2 = and this=20 is the output I get. I would be = pleased if=20 you could give me any advice as to what to do to resolve this = problem. I am using=20 python version 1.5 on Linux release 6.0 (Hedwig) Kernel 2.2.5-22 = on an=20 i586

Error in = %s at %d:=20 %s ('setup.cfg', 21, "'[bdist_rpm]\\012'")
Error in %s at %d: %s=20 ('setup.cfg', 24, "'doc_files =3D CHANGES.txt\\012'")
Traceback = (innermost=20 last):
  File "setup.py", line 13, in ?
    = setup=20 (name =3D "Distutils",
  File "distutils/core.py", line 110, in=20 setup
    dist.parse_config_files()
  File=20 "distutils/dist.py", line 323, in = parse_config_files
   =20 parser.read(filename)
  File = "/usr/lib/python1.5/ConfigParser.py", line=20 154, in read
    self.__read(fp)
  File=20 "/usr/lib/python1.5/ConfigParser.py", line 232, in = __read
   =20 cursect =3D cursect[optname] + '\n ' + value
TypeError: expected = integer=20 index

This = is the contents=20 of setup.cfg
 
#
# = setup.cfg
#
# the Distutils config file.  Just as with the = Distutils=20 setup script, this
# has the dual purpose of being used to distribute = the=20 Distutils and
# serving as an example of some of the things you can = do with=20 Distutils
# config files.  Currently, this is only useful for me = (assuming I'm the
# only person who creates Distutils source and RPM=20 distributions), but you
# could add build and installation = preferences here,=20 too.  (Although those
# sorts of things are probably best = handled on a=20 site-wide or per-user
# basis, rather than in the config file for = each module=20 distribution.)
#
# created 2000/05/31, Greg Ward
#
# $Id:=20 setup.cfg,v 1.3 2000/06/30 03:45:44 gward Exp $
#
 
[sdist]
formats=3Dgztar,zip
 
[bdist_rpm]
release =3D 1
packager =3D = Greg Ward=20 <gward@python.net>
doc_files = =3D=20 CHANGES.txt
         &nbs= p; =20 README.txt
          = ; =20 USAGE.txt
          =  =20 doc/
           = ;=20 examples/
 
changelog=20 =3D
  * Thu Jun 29 2000 Greg Ward <gward@python.net> 0.9
  = - Made=20 myself the packager, since I can now create the RPM on my=20 own
 
  = * Sun Jun 04=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.9pre-1
  - Made=20 sure scripts are file names, filled in some help strings,=20 formatted
    changelog correctly
 
  = * Wed May 31=20 2000 Greg Ward <gward@python.net>=20 0.8.3pre-1
  - Hacked up bdist_rpm.py, moved meta-data into=20 setup.cfg
 
  = * Thu May 10=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-3
  - Added=20 new options to package_data
 
  = * Tue May 09=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-2
  -=20 Include RPM_OPT_FLAGS in distutils
 
  = * Wed Apr 26=20 2000 Harry Henry Gebel <hgebel@inet.net> = 0.8.2-1
  - First=20 test of bdist_rpm
 
Thank=20 you
Steffan. G.=20 Bowen
 
=00 ------_=_NextPart_001_01C28FB0.32314120-- ------=_NextPartTM-000-5a53145d-91f0-4b39-9ec6-e9aec53a5e80 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ------------------------------------------------------------- Mae'r e-bost hwn ac unrhyw atodiad iddo yn gyfrinachol ac fe'i bwriedir ar gyfer y sawl a enwir arno yn unig. Gall gynnwys gwybodaeth freintiedig. Os yw wedi eich cyrraedd trwy gamgymeriad ni ellwch ei gopio, ei ddosbarthu na'i ddangos i unrhyw un arall a dylech gysylltu â'r Cyngor ar unwaith. Mae unrhyw gynnwys nad yw'n ymwneud â busnes swyddogol Cyngor Gwynedd yn bersonol i'r awdur ac nid yw'n awdurdodedig gan y Cyngor. ------------------------------------------------------------- This email and any attachments are confidential and intended for the named recipient only. The content may contain privileged information. If it has reached you by mistake, you should not copy, distribute or show the content to anyone but should contact Gwynedd Council at once. Any content that is not pertinent to Gwynedd Council business is personal to the author, and is not necessarily the view of the Council. ------------------------------------------------------------- ------=_NextPartTM-000-5a53145d-91f0-4b39-9ec6-e9aec53a5e80-- From akuchlin@mems-exchange.org Tue Nov 19 11:03:06 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Nov 19 11:03:06 2002 Subject: [Distutils] New Distutils snapshot Message-ID: I've made a snapshot release of the Distutils, distutils-20021119, that will become a 1.0.3 release. The code is the same as that in Python 2.2.2, with none of the recent bugfixes; this is being done for the sake of completeness, and as a test run for the 1.0.4 release (which should run in parallel with the release of Python 2.3). Anyway, it would be very helpful if you grab a copy of the snapshot from http://www.python.org/sigs/distutils-sig/download/ and take a look at it, and maybe try installing it. I don't expect there to be serious problems with the Distutils code itself (it *is* the same as 2.2.2, after all) but there are still shortcomings in the accompanying documentation and examples. Known problems that I'd like to fix for 1.0.4: * the examples (PyXML, PIL) are for old versions of their respective packages. * the test suite (not included in the snapshot, but available from CVS) is seriously broken. * fix the bdist_dumb relative path problem Please point out any other issues, or, if you have CVS access, go ahead and fix them. --amk (www.amk.ca) HELENA: And though she be but little, she is fierce. -- _A Midsummer Night's Dream_, III, ii From theller@python.net Tue Nov 19 11:51:02 2002 From: theller@python.net (Thomas Heller) Date: Tue Nov 19 11:51:02 2002 Subject: [Distutils] Re: New Distutils snapshot References: Message-ID: > Known problems that I'd like to fix for 1.0.4: > > * the examples (PyXML, PIL) are for old versions of their > respective packages. > > * the test suite (not included in the snapshot, but available from > CVS) is seriously broken. > > * fix the bdist_dumb relative path problem > > Please point out any other issues, or, if you have CVS access, go > ahead and fix them. > I assume 1.0.4 would then be the (still 1.5.2 compatible) CVS HEAD version? In this case I want to add documentation for the recent bdist_wininst improvements. I would also consider SF bug #638595, because it also has bitten me. How much time do we have? Thomas From akuchlin@mems-exchange.org Tue Nov 19 13:43:05 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Nov 19 13:43:05 2002 Subject: [Distutils] Re: New Distutils snapshot In-Reply-To: References: Message-ID: <20021119184212.GA905@ute.mems-exchange.org> On Tue, Nov 19, 2002 at 05:50:13PM +0100, Thomas Heller wrote: >I assume 1.0.4 would then be the (still 1.5.2 compatible) CVS HEAD version? Yes; 1.0.4 would wrap up the Distutils that goes into Python 2.3. >In this case I want to add documentation for the recent bdist_wininst >improvements. I would also consider SF bug #638595, because it also >has bitten me. #638595 is "Move bdist_wininst source code into PC", a directive from Guido but not actually a bug. Was that the bug you intended? >How much time do we have? Python 2.3 schedule calls for a Christmas-ish alpha1. It would be nice if all of the code fixes can be done for alpha1, so they get the maximum amount of testing. --amk (www.amk.ca) LEAR: Her voice was ever soft, Gentle, and low, an excellent thing in woman. -- _King Lear_, V, iii From theller@python.net Tue Nov 19 14:02:01 2002 From: theller@python.net (Thomas Heller) Date: Tue Nov 19 14:02:01 2002 Subject: [Distutils] Re: New Distutils snapshot References: <20021119184212.GA905@ute.mems-exchange.org> Message-ID: Andrew Kuchling writes: > On Tue, Nov 19, 2002 at 05:50:13PM +0100, Thomas Heller wrote: > >I assume 1.0.4 would then be the (still 1.5.2 compatible) CVS HEAD version? > > Yes; 1.0.4 would wrap up the Distutils that goes into Python 2.3. but also be released separately for Python 2.2.2, I assume? > > >In this case I want to add documentation for the recent bdist_wininst > >improvements. I would also consider SF bug #638595, because it also > >has bitten me. > > #638595 is "Move bdist_wininst source code into PC", a directive from > Guido but not actually a bug. Was that the bug you intended? No, it was 639118: archiver should use zipfile before zip. Sorry for the confusion. Thomas From rjones@ekit-inc.com Wed Nov 20 21:16:04 2002 From: rjones@ekit-inc.com (Richard Jones) Date: Wed Nov 20 21:16:04 2002 Subject: [Distutils] [updates] PEP 301 -- Package Index and Metadata for Distutils Message-ID: <200211211314.15032.rjones@ekit-inc.com> [if you reply to this message, please only reply to one of the mailing lists!] Hi everyone, PEP 301 has been updated: - changes to the success/failure indicators used by the register.py command. Originally I had copied the idea of using X-PyPI-* headers from PEP 243. Upon advice from Greg Stein, I have switched to using HTTP response codes. - clarifications to Roles - added PKG-INFO upload interface - included overview of online index database schema - updated deliverables in the Reference Implementation section - included implememtation detail for "classifiers" keyword - have implemented the trove classifiers, so various parts of the PEP to reflect reality Also, the web interface and register distutils command have had some development work too: - added Trove metadata to the database, including registration of it, verification and dumping - added "latest stable" release field (unused at the moment) - handle multiline descriptions in PKG-INFO uploads (yay for the email package) - switched from X-Pypi-* headers to HTTP response codes as per PEP - lots of HTML interface cleaning including better stylesheet usage and a nicer navigation bar, better support for logging in and out and finally a single place to go for submitting information There's still a bit to do, but I'd rather wait until I know whether the PEP is to be accepted or not before I start applying spit-n-polish :) Links: PEP: http://www.python.org/peps/pep-0301.html Web: http://www.amk.ca/cgi-bin/pypi.cgi Richard From akuchlin@mems-exchange.org Thu Nov 21 14:43:01 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Nov 21 14:43:01 2002 Subject: [Distutils] Proposed bdist_dumb fix Message-ID: Here's a proposed patch to alleviate the bdist_dumb problem. (Patch also attached to bug #410541.) It adds a --from-root Boolean option to bdist_dumb. from-root defaults to true, in which case you get the current behaviour. If you set it to false, the archive is built from $base, not /, so you end up with an archive containing ./lib/python2.3/site-packages/my-package on Unix. On Windows you should end up with ./Lib/site-packages/mypackage, ./Include/mypackage.h, etc. Ditto for the Mac. The only problem is on Unix if $platbase is different from $base. For example, you're installing Python code into /usr/share and C extensions into /usr/local/. Here the code simply throws up its hands and raises an exception. Thoughts? Is this a good solution? Does it work as I expect on Windows and MacOS 9? --amk (www.amk.ca) I'll never be cruel to an electron in a particle accelerator again. -- The Doctor, in "The Pirate Planet" Index: bdist_dumb.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/bdist_dumb.py,v retrieving revision 1.22 diff -u -r1.22 bdist_dumb.py --- bdist_dumb.py 19 Nov 2002 13:12:28 -0000 1.22 +++ bdist_dumb.py 21 Nov 2002 19:35:10 -0000 @@ -33,9 +33,13 @@ "directory to put final built distributions in"), ('skip-build', None, "skip rebuilding everything (for testing/debugging)"), + ('from-root=', None, + "build the archive using paths from the root directory " + "and not relative paths " + "(default: true)"), ] - boolean_options = ['keep-temp', 'skip-build'] + boolean_options = ['keep-temp', 'skip-build', 'from-root'] default_format = { 'posix': 'gztar', 'nt': 'zip', @@ -49,7 +53,8 @@ self.keep_temp = 0 self.dist_dir = None self.skip_build = 0 - + self.from_root = 1 + # initialize_options() @@ -97,9 +102,29 @@ if os.name == "os2": archive_basename = archive_basename.replace(":", "-") - self.make_archive(os.path.join(self.dist_dir, archive_basename), - self.format, - root_dir=self.bdist_dir) + pseudoinstall_root = os.path.join(self.dist_dir, archive_basename) + if self.from_root: + archive_root = self.bdist_dir + else: + if (self.distribution.has_ext_modules() and + (install.install_base != install.install_platbase)): + raise DistutilsPlatformError, \ + ("can't make a dumb built distribution where " + "base and platbase are different (%s, %s)" + % (repr(install.install_base), + repr(install.install_platbase))) + else: + # install_base usually is a full path; we need to + # make it a relative path so it can be the second argument + # to os.path.join(). + t = install.install_base + if t[0:1] == os.sep: + t = t[1:] + archive_root = os.path.join(self.bdist_dir, t) + + # Make the archive + self.make_archive(pseudoinstall_root, + self.format, root_dir=archive_root) if not self.keep_temp: remove_tree(self.bdist_dir, dry_run=self.dry_run) From theller@python.net Thu Nov 21 15:25:13 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 21 15:25:13 2002 Subject: [Distutils] Re: Proposed bdist_dumb fix In-Reply-To: References: Message-ID: Andrew Kuchling writes: > Here's a proposed patch to alleviate the bdist_dumb problem. (Patch > also attached to bug #410541.) > > It adds a --from-root Boolean option to bdist_dumb. from-root > defaults to true, in which case you get the current behaviour. If you > set it to false, the archive is built from $base, not /, so you end up > with an archive containing ./lib/python2.3/site-packages/my-package on > Unix. On Windows you should end up with > ./Lib/site-packages/mypackage, ./Include/mypackage.h, etc. Ditto for > the Mac. > > The only problem is on Unix if $platbase is different from $base. For > example, you're installing Python code into /usr/share and C > extensions into /usr/local/. Here the code simply throws up its hands > and raises an exception. > > Thoughts? Is this a good solution? Does it work as I expect on > Windows and MacOS 9? > > --amk (www.amk.ca) > I'll never be cruel to an electron in a particle accelerator again. > -- The Doctor, in "The Pirate Planet" > > Index: bdist_dumb.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/bdist_dumb.py,v > retrieving revision 1.22 > diff -u -r1.22 bdist_dumb.py > --- bdist_dumb.py 19 Nov 2002 13:12:28 -0000 1.22 > +++ bdist_dumb.py 21 Nov 2002 19:35:10 -0000 > @@ -33,9 +33,13 @@ > "directory to put final built distributions in"), > ('skip-build', None, > "skip rebuilding everything (for testing/debugging)"), > + ('from-root=', None, > + "build the archive using paths from the root directory " > + "and not relative paths " > + "(default: true)"), > ] > > - boolean_options = ['keep-temp', 'skip-build'] > + boolean_options = ['keep-temp', 'skip-build', 'from-root'] > > default_format = { 'posix': 'gztar', > 'nt': 'zip', > @@ -49,7 +53,8 @@ > self.keep_temp = 0 > self.dist_dir = None > self.skip_build = 0 > - > + self.from_root = 1 > + > # initialize_options() > > > @@ -97,9 +102,29 @@ > if os.name == "os2": > archive_basename = archive_basename.replace(":", "-") > > - self.make_archive(os.path.join(self.dist_dir, archive_basename), > - self.format, > - root_dir=self.bdist_dir) > + pseudoinstall_root = os.path.join(self.dist_dir, archive_basename) > + if self.from_root: > + archive_root = self.bdist_dir > + else: > + if (self.distribution.has_ext_modules() and > + (install.install_base != install.install_platbase)): > + raise DistutilsPlatformError, \ > + ("can't make a dumb built distribution where " > + "base and platbase are different (%s, %s)" > + % (repr(install.install_base), > + repr(install.install_platbase))) > + else: > + # install_base usually is a full path; we need to > + # make it a relative path so it can be the second argument > + # to os.path.join(). > + t = install.install_base > + if t[0:1] == os.sep: > + t = t[1:] > + archive_root = os.path.join(self.bdist_dir, t) > + > + # Make the archive > + self.make_archive(pseudoinstall_root, > + self.format, root_dir=archive_root) > > if not self.keep_temp: > remove_tree(self.bdist_dir, dry_run=self.dry_run) > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig From theller@python.net Thu Nov 21 15:29:01 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 21 15:29:01 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: References: Message-ID: [Sorry for the previous one, still sometimes having problems with gnus] Andrew Kuchling writes: > Here's a proposed patch to alleviate the bdist_dumb problem. (Patch > also attached to bug #410541.) > This code doesn't work unchanged on Windows: > + else: > + # install_base usually is a full path; we need to > + # make it a relative path so it can be the second argument > + # to os.path.join(). > + t = install.install_base > + if t[0:1] == os.sep: > + t = t[1:] > + archive_root = os.path.join(self.bdist_dir, t) 't[0:1] == os.sep' is not a valid test for an absolute pathname, those contain drive letters on Windows. This will work, and should also work on other platforms if I understand the docs for splitdrive() correctly. else: # install_base usually is a full path; we need to # make it a relative path so it can be the second argument # to os.path.join(). t = install.install_base # on systems where a drive letter is used, split it off _, t = os.path.splitdrive(t) if t[0:1] == os.sep: t = t[1:] archive_root = os.path.join(self.bdist_dir, t) I has to use '--from-root 0' command-line flag, is it supposed to work this way, needing an argument? The paths in the zip then start with 'Lib/site-packages' and 'Scripts'. Haven't yet tried older python versions, where Lib/site-packages was not yet used, see PEP 250. Thomas From akuchlin@mems-exchange.org Thu Nov 21 15:39:32 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Nov 21 15:39:32 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: References: Message-ID: <20021121203849.GA13290@ute.mems-exchange.org> On Thu, Nov 21, 2002 at 09:28:28PM +0100, Thomas Heller wrote: >This will work, and should also work on other platforms if I understand >the docs for splitdrive() correctly. Incorporated in an updated version of the patch; thanks! >I has to use '--from-root 0' command-line flag, is it supposed to work this way, >needing an argument? Well, if we want to stay backward compatible with the old behaviour, from-root has to default to true, so you need to supply an argument of 0 to turn it off. Do we feel comfortable changing the default to false? (I don't have a problem with that, and have done so in the revised patch.) Or we could turn the option around and have it be a --relative option instead. >The paths in the zip then start with 'Lib/site-packages' and >'Scripts'. Haven't yet tried older python versions, where >Lib/site-packages was not yet used, see PEP 250. >From my reading of the Windows installation schemes at the top of commands/install.py, it should also be fine there. --amk From theller@python.net Thu Nov 21 15:45:03 2002 From: theller@python.net (Thomas Heller) Date: Thu Nov 21 15:45:03 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: <20021121203849.GA13290@ute.mems-exchange.org> References: <20021121203849.GA13290@ute.mems-exchange.org> Message-ID: <65uqtzy3.fsf@python.net> > >I has to use '--from-root 0' command-line flag, is it supposed to work this way, > >needing an argument? > > Well, if we want to stay backward compatible with the old behaviour, > from-root has to default to true, so you need to supply an argument of > 0 to turn it off. Do we feel comfortable changing the default to > false? (I don't have a problem with that, and have done so in the > revised patch.) Or we could turn the option around and have it be > a --relative option instead. I don't care too much - won't use it anyway. Otherwise I would probably like --relative more. What surprised me is that you have to supply an argument to a boolean option. bdist_wininst has a --keep-temp boolean flag, but this doesn't need an argument. Neither does --verbose or --quiet. Thomas From knight@baldmt.com Thu Nov 21 16:08:52 2002 From: knight@baldmt.com (Steven Knight) Date: Thu Nov 21 16:08:52 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: Message-ID: > 't[0:1] == os.sep' is not a valid test for an absolute pathname, > those contain drive letters on Windows. > This will work, and should also work on other platforms if I understand > the docs for splitdrive() correctly. > > else: > # install_base usually is a full path; we need to > # make it a relative path so it can be the second argument > # to os.path.join(). > t = install.install_base > # on systems where a drive letter is used, split it off > _, t = os.path.splitdrive(t) > if t[0:1] == os.sep: > t = t[1:] > archive_root = os.path.join(self.bdist_dir, t) This still isn't completely correct. To really identify an absolute pathname, you should use the os.path.isabs() function provided for that purpose: _, t = os.path.splitdrive(t) if os.path.isabs(t): t = t[1:] archive_root = os.path.join(self.bdist_dir, t) Directly examining the first character loses on some systems. Old MacOS path names use a leading separator (:) to specify a *relative* path name, for example. --SK From Andrew.MacIntyre@aba.gov.au Thu Nov 21 18:25:01 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Thu Nov 21 18:25:01 2002 Subject: [Distutils] Proposed bdist_dumb fix Message-ID: > From: Thomas Heller [mailto:theller@python.net] > Sent: Friday, 22 November 2002 7:45 AM > To: akuchlin@mems-exchange.org > Cc: distutils-sig@python.org > Subject: Re: [Distutils] Proposed bdist_dumb fix > > > > >I has to use '--from-root 0' command-line flag, is it > supposed to work this way, > > >needing an argument? > > > > Well, if we want to stay backward compatible with the old behaviour, > > from-root has to default to true, so you need to supply an > argument of > > 0 to turn it off. Do we feel comfortable changing the default to > > false? (I don't have a problem with that, and have done so in the > > revised patch.) Or we could turn the option around and have it be > > a --relative option instead. > I don't care too much - won't use it anyway. Otherwise I > would probably > like --relative more. > > What surprised me is that you have to supply an argument to a boolean > option. bdist_wininst has a --keep-temp boolean flag, but this doesn't > need an argument. Neither does --verbose or --quiet. I recall someone (MAL?) not wanting the default changed. I think I prefer the --relative approach. Is your revised patch accessible somewhere? I'd like check it out on OS/2 when I get home. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From amk@amk.ca Thu Nov 21 20:25:01 2002 From: amk@amk.ca (A.M. Kuchling) Date: Thu Nov 21 20:25:01 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: ; from knight@baldmt.com on Thu, Nov 21, 2002 at 03:05:25PM -0600 References: Message-ID: <20021121205506.A11156@nyman.amk.ca> On Thu, Nov 21, 2002 at 03:05:25PM -0600, Steven Knight wrote: > _, t = os.path.splitdrive(t) > if os.path.isabs(t): > t = t[1:] > archive_root = os.path.join(self.bdist_dir, t) > >Directly examining the first character loses on some systems. Old MacOS >path names use a leading separator (:) to specify a *relative* path >name, for example. Hm, so won't this code still be incorrect on the Mac? Will it have to be something like this? if os.path.isabs(t): if platform == 'macos': t = os.sep + t else: t = t[1:] --amk From mal@lemburg.com Fri Nov 22 03:15:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri Nov 22 03:15:02 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: References: Message-ID: <3DDDEFA0.8060303@lemburg.com> Andrew MacIntyre wrote: > >From: Thomas Heller [mailto:theller@python.net] > >Sent: Friday, 22 November 2002 7:45 AM > >To: akuchlin@mems-exchange.org > >Cc: distutils-sig@python.org > >Subject: Re: [Distutils] Proposed bdist_dumb fix > > > > > > > >>>I has to use '--from-root 0' command-line flag, is it > > > >supposed to work this way, > > > >>>needing an argument? > >> > >>Well, if we want to stay backward compatible with the old behaviour, > >>from-root has to default to true, so you need to supply an > > > >argument of > > > >>0 to turn it off. Do we feel comfortable changing the default to > >>false? (I don't have a problem with that, and have done so in the > >>revised patch.) Or we could turn the option around and have it be > >>a --relative option instead. > > > >I don't care too much - won't use it anyway. Otherwise I > >would probably > >like --relative more. > > > >What surprised me is that you have to supply an argument to a boolean > >option. bdist_wininst has a --keep-temp boolean flag, but this doesn't > >need an argument. Neither does --verbose or --quiet. > > > I recall someone (MAL?) not wanting the default changed. I think > I prefer the --relative approach. IMHO, when extending distutils you should always keep the current defaults and add new functionality via options. A --relative option sounds like the way to go. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From knight@baldmt.com Fri Nov 22 05:47:06 2002 From: knight@baldmt.com (Steven Knight) Date: Fri Nov 22 05:47:06 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: <20021121205506.A11156@nyman.amk.ca> Message-ID: > > _, t = os.path.splitdrive(t) > > if os.path.isabs(t): > > t = t[1:] > > archive_root = os.path.join(self.bdist_dir, t) > > > >Directly examining the first character loses on some systems. Old MacOS > >path names use a leading separator (:) to specify a *relative* path > >name, for example. > > Hm, so won't this code still be incorrect on the Mac? Will it have to > be something like this? > > if os.path.isabs(t): > if platform == 'macos': > t = os.sep + t > else: > t = t[1:] You're right. I paid too much attention to the problem with the test and didn't think through the solution properly. Good catch; apologies for the oversight on my part. --SK From akuchlin@mems-exchange.org Mon Nov 25 08:49:54 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Nov 25 08:49:54 2002 Subject: [Distutils] Proposed bdist_dumb fix In-Reply-To: <3DDDEFA0.8060303@lemburg.com> References: <3DDDEFA0.8060303@lemburg.com> Message-ID: <20021125134852.GA21652@ute.mems-exchange.org> On Fri, Nov 22, 2002 at 09:49:36AM +0100, M.-A. Lemburg wrote: >IMHO, when extending distutils you should always keep the current >defaults and add new functionality via options. A --relative >option sounds like the way to go. OK, done; I've changed www.python.org/sf/410541 to use --relative instead. Any further comments, or can I check it in? --amk (www.amk.ca) MOROCCO: (Reads) Gilded tombs do worms enfold. -- _The Merchant of Venice_, II, vii From gward@python.net Mon Nov 25 14:21:42 2002 From: gward@python.net (Greg Ward) Date: Mon Nov 25 14:21:42 2002 Subject: [Distutils] fwd: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. Message-ID: <20021125192047.GA3149@cthulhu.gerg.ca> --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can someone verify this bug report and, if appropriate, apply the included patch? Thanks -- -- Greg Ward http://www.gerg.ca/ Vote Cthulhu -- why settle for a lesser evil? --SLDf9lqlvOQaIe6s Content-Type: message/rfc822 Content-Disposition: inline Return-path: Envelope-to: greg@gerg.ca Delivery-date: Mon, 25 Nov 2002 12:31:17 -0500 Received: from mail.mailkeep.net ([204.92.85.50] helo=smtp.mailkeep.net) by cthulhu.gerg.ca with smtp (Exim 4.05) id 18GN4m-0000kK-00 for greg@gerg.ca; Mon, 25 Nov 2002 12:31:16 -0500 Received: from starship.python.net ([12.155.117.32]) by smtp.mailkeep.net with SMTP (Mailkeep 1.2) id 02112512231842052 for greg@gerg.ca; Mon, 25 Nov 2002 12:23:18 -0500 Received: from [216.140.23.68] (helo=msi03-mail.noam.msiusa.com ident=TK) by starship.python.net with esmtp (Exim 4.10) id 18GN4i-0001vv-00 for gward@python.net; Mon, 25 Nov 2002 12:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C294A8.71C69617" Subject: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. Date: Mon, 25 Nov 2002 12:31:10 -0500 Message-ID: <970F565A5733E64686BC3A10FBBAE87C02104D@msi03-mail.noam.msiusa.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. Thread-Index: AcKUqHRxUsEtLgBZEdex5ABQBLK2hg== From: "Stambaugh, Wayne" To: X-Spam-Status: No, hits=1.6 required=5.0 tests=DEAR_SOMEBODY,SPAM_PHRASE_03_05 X-Spam-Level: * This is a multi-part message in MIME format. ------_=_NextPart_001_01C294A8.71C69617 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Distutils.sysconfig.get_python_lib() always returns absolute path = in win32.

Dear Mr. Ward,

I know I probably shouldn't be sending this to = you.  However, your name is plastered all over the distutils source = and documentation so I figured you would be the logical person to send = this patch to.  I'll understand if you tell me to take a flying = leap but it seemed like overkill to register at SourceForge for this one = patch.  I promise if this becomes a regular habit, I'll register at = SourceForge and submit patches in the appropriate manner.  I = browsed the bug and patch managers and didn't see any patches or bug = reports matching what I believe to be a bug in the get_python_lib() = function in the distutils sysconfig.py file in the win32 version of = Python 2.2.2.  When os.name =3D=3D "nt" and sys.version = > 2.2, get_python_lib() always returns the absolute path when the = plat_specific argument is true.  Maybe I'm showing my ignorance but = I'm guessing that get_python_lib(1,0,'') should return the relative path = as it does for all the other cases.

Thanks for your patience.  I know this doesn't = get said nearly enough, thanks for the hard work you put into making = Python the great language.

Regards,

Wayne Stambaugh=A0
Principal Engineer
Schaevitz Sensors


Wayne Stambaugh=A0
Principal Engineer
Schaevitz Sensors

------_=_NextPart_001_01C294A8.71C69617 Content-Type: application/octet-stream; name="sysconfig.diff" Content-Transfer-Encoding: base64 Content-Description: sysconfig.diff Content-Disposition: attachment; filename="sysconfig.diff" KioqIHN5c2NvbmZpZy5weX4JVHVlIE9jdCAgOCAxOTo0NjowNCAyMDAyCi0tLSBzeXNjb25maWcu cHkJTW9uIE5vdiAyNSAxMTowNTowMiAyMDAyCioqKioqKioqKioqKioqKgoqKiogMTEwLDExNiAq KioqCiAgICAgICAgICAgICAgaWYgc3lzLnZlcnNpb24gPCAiMi4yIjoNCiAgICAgICAgICAgICAg ICAgIHJldHVybiBwcmVmaXgNCiAgICAgICAgICAgICAgZWxzZToNCiEgICAgICAgICAgICAgICAg IHJldHVybiBvcy5wYXRoLmpvaW4oUFJFRklYLCAiTGliIiwgInNpdGUtcGFja2FnZXMiKQ0KICAN CiAgICAgIGVsaWYgb3MubmFtZSA9PSAibWFjIjoNCiAgICAgICAgICBpZiBwbGF0X3NwZWNpZmlj Og0KLS0tIDExMCwxMTYgLS0tLQogICAgICAgICAgICAgIGlmIHN5cy52ZXJzaW9uIDwgIjIuMiI6 DQogICAgICAgICAgICAgICAgICByZXR1cm4gcHJlZml4DQogICAgICAgICAgICAgIGVsc2U6DQoh ICAgICAgICAgICAgICAgICByZXR1cm4gb3MucGF0aC5qb2luKHByZWZpeCwgIkxpYiIsICJzaXRl LXBhY2thZ2VzIikNCiAgDQogICAgICBlbGlmIG9zLm5hbWUgPT0gIm1hYyI6DQogICAgICAgICAg aWYgcGxhdF9zcGVjaWZpYzoNCg== ------_=_NextPart_001_01C294A8.71C69617-- --SLDf9lqlvOQaIe6s-- From akuchlin@mems-exchange.org Mon Nov 25 15:07:32 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon Nov 25 15:07:32 2002 Subject: [Distutils] fwd: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. In-Reply-To: <20021125192047.GA3149@cthulhu.gerg.ca> References: <20021125192047.GA3149@cthulhu.gerg.ca> Message-ID: <20021125200504.GA23471@ute.mems-exchange.org> De-HTMLifying... ... I browsed the bug and patch managers and didn't see any patches or bug reports matching what I believe to be a bug in the get_python_lib() function in the distutils sysconfig.py file in the win32 version of Python 2.2.2. When os.name == "nt" and sys.version > 2.2, get_python_lib() always returns the absolute path when the plat_specific argument is true. Maybe I'm showing my ignorance but I'm guessing that get_python_lib(1,0,'') should return the relative path as it does for all the other cases. ... *** sysconfig.py~ Tue Oct 8 19:46:04 2002 --- sysconfig.py Mon Nov 25 11:05:02 2002 *************** *** 110,116 **** if sys.version < "2.2": return prefix else: ! return os.path.join(PREFIX, "Lib", "site-packages") elif os.name == "mac": if plat_specific: --- 110,116 ---- if sys.version < "2.2": return prefix else: ! return os.path.join(prefix, "Lib", "site-packages") elif os.name == "mac": if plat_specific: At the start of this function, there are the lines: if prefix is None: prefix = plat_specific and EXEC_PREFIX or PREFIX So using PREFIX certainly looks incorrect; 'prefix' uses EXEC_PREFIX or PREFIX as appropriate. Can someone on NT please verify? Just after the branch for os.name == "mac", the OS/2 code also uses PREFIX: elif os.name == "os2": if standard_lib: return os.path.join(PREFIX, "Lib") else: return os.path.join(PREFIX, "Lib", "site-packages") Should this be fixed, too? --amk (www.amk.ca) Abstraction is one of those notions that Python tosses out the window, yet expresses very well. -- Gordon McMillan, 6 Jan 2000 From Andrew.MacIntyre@aba.gov.au Mon Nov 25 17:51:42 2002 From: Andrew.MacIntyre@aba.gov.au (Andrew MacIntyre) Date: Mon Nov 25 17:51:42 2002 Subject: [Distutils] fwd: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. Message-ID: > Just after the branch for os.name == "mac", the OS/2 code > also uses PREFIX: > > elif os.name == "os2": > if standard_lib: > return os.path.join(PREFIX, "Lib") > else: > return os.path.join(PREFIX, "Lib", "site-packages") > > Should this be fixed, too? Only if you want to break Distutils on OS/2, which I'd prefer you didn't because it works nicely just as is. ----------------------------------------------------------------------- Andrew MacIntyre \ E-mail: andrew.macintyre@aba.gov.au Planning & Licensing Branch \ Tel: +61 2 6256 2812 Australian Broadcasting Authority \ Fax: +61 2 6253 3277 -> "These thoughts are mine alone!" <---------------------------------- From mal@lemburg.com Tue Nov 26 04:29:39 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue Nov 26 04:29:39 2002 Subject: [Distutils] fwd: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. References: <20021125192047.GA3149@cthulhu.gerg.ca> <20021125200504.GA23471@ute.mems-exchange.org> Message-ID: <3DE33E79.1030908@lemburg.com> Andrew Kuchling wrote: > De-HTMLifying... > ... > > I browsed the bug and patch managers and didn't see any patches or > bug reports matching what I believe to be a bug in the > get_python_lib() function in the distutils sysconfig.py file in the > win32 version of Python 2.2.2. When os.name == "nt" and sys.version > > 2.2, get_python_lib() always returns the absolute path when the > plat_specific argument is true. Maybe I'm showing my ignorance but > I'm guessing that get_python_lib(1,0,'') should return the relative > path as it does for all the other cases. I suppose this is for Thomas Heller to answer. Perhaps the bdist_wininst command relies on this. Why is it relevant whether get_python_lib() returns a relative or an absolute path ? > ... > > *** sysconfig.py~ Tue Oct 8 19:46:04 2002 > --- sysconfig.py Mon Nov 25 11:05:02 2002 > *************** > *** 110,116 **** > if sys.version < "2.2": > return prefix > else: > ! return os.path.join(PREFIX, "Lib", "site-packages") > > elif os.name == "mac": > if plat_specific: > --- 110,116 ---- > if sys.version < "2.2": > return prefix > else: > ! return os.path.join(prefix, "Lib", "site-packages") > > elif os.name == "mac": > if plat_specific: > > At the start of this function, there are the lines: > > if prefix is None: > prefix = plat_specific and EXEC_PREFIX or PREFIX > > So using PREFIX certainly looks incorrect; 'prefix' uses EXEC_PREFIX > or PREFIX as appropriate. Can someone on NT please verify? > > Just after the branch for os.name == "mac", the OS/2 code > also uses PREFIX: > > elif os.name == "os2": > if standard_lib: > return os.path.join(PREFIX, "Lib") > else: > return os.path.join(PREFIX, "Lib", "site-packages") > > Should this be fixed, too? > > --amk (www.amk.ca) > Abstraction is one of those notions that Python tosses out the window, yet > expresses very well. > -- Gordon McMillan, 6 Jan 2000 > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From akuchlin@mems-exchange.org Tue Nov 26 08:39:09 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Tue Nov 26 08:39:09 2002 Subject: [Distutils] fwd: Distutils.sysconfig.get_python_lib() always returns absolute path in win32. In-Reply-To: <3DE33E79.1030908@lemburg.com> References: <20021125192047.GA3149@cthulhu.gerg.ca> <20021125200504.GA23471@ute.mems-exchange.org> <3DE33E79.1030908@lemburg.com> Message-ID: <20021126133817.GB24347@ute.mems-exchange.org> On Tue, Nov 26, 2002 at 10:27:21AM +0100, M.-A. Lemburg wrote: >Why is it relevant whether get_python_lib() returns a >relative or an absolute path ? I don't think get_python_lib() ever returns a relative path, so that part of the original poster's diagnosis is incorrect. I just noticed the inconsistency in usage of prefix and PREFIX as a result. --amk (www.amk.ca) "Such minds, Hinton, shaping infinity itself." -- Gull, in FROM HELL #2