Re: [Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53
"M.-A. Lemburg"
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
"MH" == Michael Hudson
writes:
MH> "M.-A. Lemburg"
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
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/
"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
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"
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/
In article <2mbs52pn2d.fsf@starship.python.net>, Michael Hudson
"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
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/
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/
"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
participants (5)
-
Andrew Kuchling
-
Jeremy Hylton
-
M.-A. Lemburg
-
Michael Hudson
-
Robin Becker