Re: [Python-Dev] Package install failures in 2.6.3
If setuptools can be made to work with Python 2.6.3 /and/ earlier versions of Python 2.6.x, then it should be patched and an update released. If not, then perhaps we should revert the change in a quick Python 2.6.4. If there is going to be any quick 2.6.4 release, can you consider a fix to the building of extensions under Windows ( http://bugs.python.org/issue4120 )? Extensions built without this patch applied will not work if the MSVC9 runtimes are installed locally (in the Python folder) instead of system-wide (WinSxS). PIL and Matplotlib now use this patch when building extensions. But many others (e.g. PyGame) still create problematic extensions. -Koen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 7, 2009, at 10:54 AM, Koen van de Sande wrote: If there is going to be any quick 2.6.4 release, can you consider a fix to the building of extensions under Windows ( http://bugs.python.org/issue4120 )? Extensions built without this patch applied will not work if the MSVC9 runtimes are installed locally (in the Python folder) instead of system-wide (WinSxS). PIL and Matplotlib now use this patch when building extensions. But many others (e.g. PyGame) still create problematic extensions. I'm not in favor of including this in 2.6.4 since this wasn't a regression in 2.6.3. However if Martin von Loewis approves of the patch and feels strongly that it should go in 2.6.4, I'll allow it. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
2009/10/6 P.J. Eby p...@telecommunity.com: At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote: Setuptools development has been discontinued for a year, and does patches on Distutils code. Some of these patches are sensitive to any change made on Distutils, wether those changes are internal or not. Setuptools is also not the only thing out there that subclasses distutils commands in general, or the build_ext command in particular. Numpy, Twisted, the mx extensions... there are plenty of things out there that subclass distutils commands, quite in adherence to the rules. (Note too that subclassing != patching, and the ability to subclass and substitute distutils commands is documented.) It's therefore not appropriate to treat the issue as if it were setuptools-specific; it could have broken any other major (or minor) package's subclassing of the build_ext command. The internal vs published API difference does not make much sense in distutils case anyway, since a lot of implementation details are necessary to make non trivial extension work. When working on numpy.distutils, I almost always have to look at distutils sources since the docs are vastly insufficient, and even then, the code is so bad that quite often the only way to interact with distutils is to reverse engineer its behavior by trial and error. cheers, David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé wrote: Notice that I am also doing nightly builds of Distutils that can be installed and tried in released version of Python, and that can be used instead of the Python's embed Distutils (see the installable tarballs at nightly.ziade.org). so maybe it's just a matter of continuous integration Could these be released as normal sdist packages on PyPI? That would seem the best way to get them used... (bonus points for working with buildout,virtualenv,pip,etc) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Barry Warsaw wrote: 2) PJE releases a new version of setuptools that fixes this problem. 3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. on cheeseshop) and releases a new version It's a shame you didn't suggest this sooner. It would have avoided the need for the seperate Distribute project and all the horrible hacks it entails for every package that uses setuptools... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 2:06 PM, Ned Deily n...@acm.org wrote: Assuming that distutils is not changed in a forthcoming 2.6.4 Since the changes made in Distutils were bug fixes that kept all public API backward compatible, I don't see why this should be changed. Setuptools development has been discontinued for a year, and does patches on Distutils code. Some of these patches are sensitive to any change made on Distutils, wether those changes are internal or not. It's up to the Setuptools project to provide a release that fixes this problem. And this fix is one or two lines long. Distutils will *not* check in its code if it was patched by Setuptools, to make sure Setuptools 0.6c9 still works. I'm not proposing to debate the merits of all of the options here. However, if a 2.6.4 release is to be pushed out quickly for other reasons, a one-time window of opportunity would be available and it would be prudent to at least consider the possibility of a distutils fix. What about a Setuptools release, with the proper fix ? Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé wrote: I'm not proposing to debate the merits of all of the options here. However, if a 2.6.4 release is to be pushed out quickly for other reasons, a one-time window of opportunity would be available and it would be prudent to at least consider the possibility of a distutils fix. What about a Setuptools release, with the proper fix ? +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote: I'm not proposing to debate the merits of all of the options here. However, if a 2.6.4 release is to be pushed out quickly for other reasons, a one-time window of opportunity would be available and it would be prudent to at least consider the possibility of a distutils fix. What about a Setuptools release, with the proper fix ? If setuptools can be made to work with Python 2.6.3 /and/ earlier versions of Python 2.6.x, then it should be patched and an update released. If not, then perhaps we should revert the change in a quick Python 2.6.4. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 3:32 PM, Barry Warsaw ba...@python.org wrote: On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote: I'm not proposing to debate the merits of all of the options here. However, if a 2.6.4 release is to be pushed out quickly for other reasons, a one-time window of opportunity would be available and it would be prudent to at least consider the possibility of a distutils fix. What about a Setuptools release, with the proper fix ? If setuptools can be made to work with Python 2.6.3 /and/ earlier versions of Python 2.6.x, then it should be patched and an update released. If not, then perhaps we should revert the change in a quick Python 2.6.4. It's technically possible to fix Setuptools. We did this fix on Distribute, and the patch is 2 lines long. But it's just a matter of having the maintainer doing it. A few months ago we couldn't make him fix and release the bug that made setuptools fail with svn 1.6, and the year before it took several months to get it fixed for svn 1.5 (a one line, not risky change !!!) That's why we have forked and created Distribute, to provide bug fixes. If PJE is not concerned anymore by the maintenance, imho he should let someone that is willing to do it take over the maintenance of his package to fix this (and the other problems). That is not a new problem. Beware that I don't want to run in any new vicious thread here: I had my share of those. So about taking over Setuptools maintenance : 1/ I am not saying it should be me, and I am not saying that I am offended that PJE didn't open the maintenance of setuptools to me. I think he should trust the community and let the maintenance of setuptools be done by all the people that are actively working on the topic. 2/ No, as someone told me in IRC, that's not an evil plan of mine to make people switch to Distribute. This is not in our interest, it's a loss-loss situation. Now I am strongly opposed to revert any bug fix change in Distutils just because it breaks Setuptools, which is unmaintained since a year. We have been struggling over a year with this issue. And we are still struggling because we have to work in a fork to try to provide solutions for the community, with a lot of bootstrapping issues. Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. We've discussed ways of doing that some years ago and found that it was not possible to make ends join. I'd much rather like to see some of the features in setuptools get implemented in distutils. eGenix could contribute a bdist_egg implementation that doesn't rely on setuptools and its monkey patches - along with some other new commands that people might find useful such as the ability to build Unix libraries, optional and self-configuring extensions, autoconf-style setups, etc. (see mxSetup.py in egenix-mx-base for all the details). We'd just need some help with integrating the things into distutils, since we currently don't have the bandwidth for such things. Aside: After importing setuptools a lot of things in distutils no longer work as advertised. This is due to the heavy monkey patching being applied in setuptools. In some cases there's on other way to adapt distutils to ones needs, but most of the times, a little more thought put into the OO design of a tool makes it possible to play nice with distutils without any monkey patching. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote: If setuptools can be made to work with Python 2.6.3 /and/ earlier versions of Python 2.6.x, then it should be patched and an update released. If not, then perhaps we should revert the change in a quick Python 2.6.4. It's technically possible to fix Setuptools. We did this fix on Distribute, and the patch is 2 lines long. My question was less about the political aspects than the technical aspects. I gather you're saying that the fix to setuptools will make it work in 2.6.3 without inadvertently breaking it for 2.6.2, 2.6.1, and 2.6.0, right? Have you tried the fix in those older versions to be sure? If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
M.-A. Lemburg wrote: Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. We've discussed ways of doing that some years ago and found that it was not possible to make ends join. [just realized that the above could be mistaken for make ends meet which has a completely different meaning in English than the German idiom; what I meant was that no consensus could be reached] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek That's why we have forked and created Distribute, to provide bug Tarek fixes. I suspect you might need to publicize this a bit better. The first I heard of Distribute or non-responsiveness of PJE regarding setuptools was this thread. (I don't read comp.lang.python anymore. I do read python-dev and comp.lang.python.announce. Maybe I just missed it.) Tarek Now I am astonished that we are talking about reverting changes Tarek in Distutils that were done for bugfixes, for a third party Tarek package that does monkey patches on Distutils. As I said, I was completely unaware of the problems you're addressing with Distribute. My guess is that many extension writers and almost certainly those people who install extensions will be similarly unaware of the issues. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw ba...@python.org wrote: If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. How do your propose to get the author of setuptools to release a new version? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 4:32 PM, Barry Warsaw ba...@python.org wrote: On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote: If setuptools can be made to work with Python 2.6.3 /and/ earlier versions of Python 2.6.x, then it should be patched and an update released. If not, then perhaps we should revert the change in a quick Python 2.6.4. It's technically possible to fix Setuptools. We did this fix on Distribute, and the patch is 2 lines long. My question was less about the political aspects than the technical aspects. I gather you're saying that the fix to setuptools will make it work in 2.6.3 without inadvertently breaking it for 2.6.2, 2.6.1, and 2.6.0, right? Have you tried the fix in those older versions to be sure? If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. Yes it does. The fix makes sure build_ext.get_ext_filename still works as it is supposed (just returning the extension of a filename depending on the environment) under all versions, *and* continues to do extra work for the Setuptools internal needs when it is called by Setuptools itself on various places. It's two lines in Setuptools. But beware that a new Setuptools release might take a few months and maybe will never happen. That is why a suggested solution was to install Distribute, because it addresses among other bug fixes, this one. Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote: Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. We've discussed ways of doing that some years ago and found that it was not possible to make ends join. I'd much rather like to see some of the features in setuptools get implemented in distutils. eGenix could contribute a bdist_egg implementation that doesn't rely on setuptools and its monkey patches - along with some other new commands that people might find useful such as the ability to build Unix libraries, optional and self-configuring extensions, autoconf-style setups, etc. (see mxSetup.py in egenix-mx-base for all the details). We'd just need some help with integrating the things into distutils, since we currently don't have the bandwidth for such things. What about making the Distribute project the laboratory for this work ? It's open to contributions. We are also planning to implement early versions of the latest PEP proposals concerning packaging in this project, once they are finished and accepted, before it goes into Distutils itself. Aside: After importing setuptools a lot of things in distutils no longer work as advertised. This is due to the heavy monkey patching being applied in setuptools. Yes the code there is very sensitive to any change. Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 4:40 PM, s...@pobox.com wrote: Tarek That's why we have forked and created Distribute, to provide bug Tarek fixes. I suspect you might need to publicize this a bit better. The first I heard of Distribute or non-responsiveness of PJE regarding setuptools was this thread. (I don't read comp.lang.python anymore. I do read python-dev and comp.lang.python.announce. Maybe I just missed it.) No you didn't miss it. That's probably my fault because the only places I publicize about it are my blog (indexed in planet python) and the distutils-SIG. Maybe I should blog a summary of the situation and post it to python annoucement as well. Tarek Now I am astonished that we are talking about reverting changes Tarek in Distutils that were done for bugfixes, for a third party Tarek package that does monkey patches on Distutils. As I said, I was completely unaware of the problems you're addressing with Distribute. My guess is that many extension writers and almost certainly those people who install extensions will be similarly unaware of the issues. Right, and an end-user can't be aware of those. But until they depend on a project that is not maintained and that we, active people, can't maintain; we will face such problems. Now I am dedicated to help all extension writers out there, and as a matter of fact I've been doing it since a few weeks on #distutils on freenode, and all the results of this work are contributed in Distribute. I have written down two important things so far from this thread: 1/ the need to provide a builbdot service for packagers that wish to try their package against the latest Distutils 2/ the need to publicize what is going on for a wider audience. Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé wrote: On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote: Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. We've discussed ways of doing that some years ago and found that it was not possible to make ends join. I'd much rather like to see some of the features in setuptools get implemented in distutils. eGenix could contribute a bdist_egg implementation that doesn't rely on setuptools and its monkey patches - along with some other new commands that people might find useful such as the ability to build Unix libraries, optional and self-configuring extensions, autoconf-style setups, etc. (see mxSetup.py in egenix-mx-base for all the details). We'd just need some help with integrating the things into distutils, since we currently don't have the bandwidth for such things. What about making the Distribute project the laboratory for this work ? It's open to contributions. The way the distutils extensions are implemented (by sub-classing distutils classes) make it easier to add them back to core distutils, rather than to integrate them into another 3rd party distutils extension. I'm not sure how adding them to Distribute would help, since then you'd only be able to access them using Distribute. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 5:26 PM, M.-A. Lemburg m...@egenix.com wrote: Tarek Ziadé wrote: On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote: Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. We've discussed ways of doing that some years ago and found that it was not possible to make ends join. I'd much rather like to see some of the features in setuptools get implemented in distutils. eGenix could contribute a bdist_egg implementation that doesn't rely on setuptools and its monkey patches - along with some other new commands that people might find useful such as the ability to build Unix libraries, optional and self-configuring extensions, autoconf-style setups, etc. (see mxSetup.py in egenix-mx-base for all the details). We'd just need some help with integrating the things into distutils, since we currently don't have the bandwidth for such things. What about making the Distribute project the laboratory for this work ? It's open to contributions. The way the distutils extensions are implemented (by sub-classing distutils classes) make it easier to add them back to core distutils, rather than to integrate them into another 3rd party distutils extension. I'm not sure how adding them to Distribute would help, since then you'd only be able to access them using Distribute. I was thinking about the release cycles but this is maybe because I am unaware of the way eGenix packages are developed, so I might be wrong. Distribute has the bandwidth to work on this with many contributors with a smaller release cycle than stdlib, allowing more feedback. Notice that I am also doing nightly builds of Distutils that can be installed and tried in released version of Python, and that can be used instead of the Python's embed Distutils (see the installable tarballs at nightly.ziade.org). so maybe it's just a matter of continuous integration Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote: If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. Yes it does. Excellent, thanks. The fix makes sure build_ext.get_ext_filename still works as it is supposed (just returning the extension of a filename depending on the environment) under all versions, *and* continues to do extra work for the Setuptools internal needs when it is called by Setuptools itself on various places. It's two lines in Setuptools. But beware that a new Setuptools release might take a few months and maybe will never happen. That is why a suggested solution was to install Distribute, because it addresses among other bug fixes, this one. I think we have two other choices. 2) PJE releases a new version of setuptools that fixes this problem. 3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. on cheeseshop) and releases a new version I still hope #2 happens, but let's have a deadline for when the more drastic measures will be taken. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 5, 2009, at 10:50 AM, Daniel Stutzbach wrote: On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw ba...@python.org wrote: If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. How do your propose to get the author of setuptools to release a new version? He either will or he won't. Let's give a deadline for when it must happen or we will do what we need to do. I think a week to 10 days is reasonable. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
-On [20091005 17:45], Barry Warsaw (ba...@python.org) wrote: 2) PJE releases a new version of setuptools that fixes this problem. Will all due respect to PJE, but I sincerely doubt this will happen. There's still a bunch of outstanding patches over at the setuptools tracker, including SVN 1.x support, which have been open for more than a year. Personally I consider setuptools unmaintained and have started moving my projects over to Distribute. So, if you decide to wait, make sure to put a deadline on it. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The earth laughs in flowers... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek No you didn't miss it. That's probably my fault because the only Tarek places I publicize about it are my blog (indexed in planet Tarek python) and the distutils-SIG. Bloggers beware!!! Not everyone reads blogs. (I don't unless someone calls my attention to something of particular interest.) Even if everyone did read blogs, the risk of missing a particular post is extremely high considering the number of planet.python.org subscriptions. I don't know how many blogs are aggregated on planet.python.org but a quick scan suggests it's well over 100 at this point. Moral of the story: If you have something to announce, announce it in the proper channel: python-announce-l...@python.org. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Hello, Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. I think we should avoid any questions of responsability here (besides, it is quite clear that you, Tarek, are not responsible for the pre-existing mess, and the lack of maintenance on certain popular software). Knowing who is responsible doesn't make our users' life any better if nothing's fixed in time. The only question is, given that 2.6.x is supposed to be a bug-fix branch, do we want to fix that incompatibility with a widely deployed existing piece of software? Whether or not the incompatibility is legitimate (i.e., whether setuptools is badly written and relies on implementation details) is beyond the point, IMO. [ The issue, of course, is quite different if we come to talk about trunk. ] If this choice wins here, it means that setuptools and the stdlib are tied together, and that the setuptools package should be integrated to the stdlib *immediatly*. Oh, certainly not. I don't think anybody would want that at this point, even the most hardcore supporters of setuptools :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote: The only question is, given that 2.6.x is supposed to be a bug-fix branch, do we want to fix that incompatibility with a widely deployed existing piece of software? Whether or not the incompatibility is legitimate (i.e., whether setuptools is badly written and relies on implementation details) is beyond the point, IMO. Right. As discussed with Barry, I will work on an internal special case in Distutils in the 2.6 maint. branch so it fixes the incompatibility with the Setuptools 0.6c9 release. Tarek. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé writes: Maybe I should blog a summary of the situation and post it to python annoucement as well. Please don't. It's unlikely to do anything except incite a lot of flames. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch,
do we
want to fix that incompatibility with a widely deployed existing piece of
software? Whether or not the incompatibility is legitimate (i.e., whether
setuptools is badly written and relies on implementation details) is beyond
the
point, IMO.
Right. As discussed with Barry, I will work on an internal special
case in Distutils in the 2.6 maint.
branch so it fixes the incompatibility with the Setuptools 0.6c9 release.
You could add a selective work-around that just triggers if setuptools
has been loaded on the 2.6 branch.
if sys.modules.has_key('setuptools'):
# monkey-patch fix-up setuptools to work with the new code
...
or the other way around:
if sys.modules.has_key('setuptools'):
# undo r1234 to make setuptools 0.6c9 happy again
...
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 05 2009)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 7:06 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch,
do we
want to fix that incompatibility with a widely deployed existing piece of
software? Whether or not the incompatibility is legitimate (i.e., whether
setuptools is badly written and relies on implementation details) is beyond
the
point, IMO.
Right. As discussed with Barry, I will work on an internal special
case in Distutils in the 2.6 maint.
branch so it fixes the incompatibility with the Setuptools 0.6c9 release.
You could add a selective work-around that just triggers if setuptools
has been loaded on the 2.6 branch.
if sys.modules.has_key('setuptools'):
# monkey-patch fix-up setuptools to work with the new code
...
or the other way around:
if sys.modules.has_key('setuptools'):
# undo r1234 to make setuptools 0.6c9 happy again
Yes I am working on this. I am putting setuptools specific build_ext
command into the distutils
tests to reproduce the issue, then will do a specific setuptools fix,
...
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 05 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote: Setuptools development has been discontinued for a year, and does patches on Distutils code. Some of these patches are sensitive to any change made on Distutils, wether those changes are internal or not. Setuptools is also not the only thing out there that subclasses distutils commands in general, or the build_ext command in particular. Numpy, Twisted, the mx extensions... there are plenty of things out there that subclass distutils commands, quite in adherence to the rules. (Note too that subclassing != patching, and the ability to subclass and substitute distutils commands is documented.) It's therefore not appropriate to treat the issue as if it were setuptools-specific; it could have broken any other major (or minor) package's subclassing of the build_ext command. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote: Now I am astonished that we are talking about reverting changes in Distutils that were done for bugfixes, for a third party package that does monkey patches on Distutils. Subclassing is not monkeypatching, so if you consider the above to be a general policy, then the developers of at least Numpy and Twisted should consider themselves warned that bugfix releases may break their build processes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Mon, Oct 5, 2009 at 08:44, Barry Warsaw ba...@python.org wrote: On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote: If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. Yes it does. Excellent, thanks. The fix makes sure build_ext.get_ext_filename still works as it is supposed (just returning the extension of a filename depending on the environment) under all versions, *and* continues to do extra work for the Setuptools internal needs when it is called by Setuptools itself on various places. It's two lines in Setuptools. But beware that a new Setuptools release might take a few months and maybe will never happen. That is why a suggested solution was to install Distribute, because it addresses among other bug fixes, this one. I think we have two other choices. 2) PJE releases a new version of setuptools that fixes this problem. 3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. on cheeseshop) and releases a new version I still hope #2 happens, but let's have a deadline for when the more drastic measures will be taken. Or we VERY clearly and loudly state in the release notes and anywhere else we can that Distribute has replaced setuptools and everyone should upgrade immediately because of critical bugs like the one under discussion. I should also mention this bug was not unknown. I discovered it after Distribute 0.6 was released as I always run cutting edge interpreters. Never bothered to report it until Distribute 0.6.1 was released which Tarek fixed in less than a week. I never bothered to report it for setuptools as I know it isn't maintained. It's probably in our best interest to just get people over to Distribute, let it continue to hijack setuptools, and slowly let that name fade out if it is going to continue to be unmaintained. I have to admit I find it really disheartening that we are letting an unmaintained project dictate how we fix a bug. I really hope this is a one-time deal and from this point forward we all move the community towards Distribute so we never feel pressured like this again. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
Brett Cannon wrote: On Mon, Oct 5, 2009 at 08:44, Barry Warsaw ba...@python.org mailto:ba...@python.org wrote: On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote: If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. Yes it does. Excellent, thanks. The fix makes sure build_ext.get_ext_filename still works as it is supposed (just returning the extension of a filename depending on the environment) under all versions, *and* continues to do extra work for the Setuptools internal needs when it is called by Setuptools itself on various places. It's two lines in Setuptools. But beware that a new Setuptools release might take a few months and maybe will never happen. That is why a suggested solution was to install Distribute, because it addresses among other bug fixes, this one. I think we have two other choices. 2) PJE releases a new version of setuptools that fixes this problem. 3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. on cheeseshop) and releases a new version I still hope #2 happens, but let's have a deadline for when the more drastic measures will be taken. Or we VERY clearly and loudly state in the release notes and anywhere else we can that Distribute has replaced setuptools and everyone should upgrade immediately because of critical bugs like the one under discussion. +1 - this sounds like a good solution. I'm intrigued as to whether setuptools does monkey patch distutils or subclass though, they are fundamentally different concepts. Michael I should also mention this bug was not unknown. I discovered it after Distribute 0.6 was released as I always run cutting edge interpreters. Never bothered to report it until Distribute 0.6.1 was released which Tarek fixed in less than a week. I never bothered to report it for setuptools as I know it isn't maintained. It's probably in our best interest to just get people over to Distribute, let it continue to hijack setuptools, and slowly let that name fade out if it is going to continue to be unmaintained. I have to admit I find it really disheartening that we are letting an unmaintained project dictate how we fix a bug. I really hope this is a one-time deal and from this point forward we all move the community towards Distribute so we never feel pressured like this again. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
On Oct 5, 2009, at 2:21 PM, Brett Cannon wrote: I should also mention this bug was not unknown. I discovered it after Distribute 0.6 was released as I always run cutting edge interpreters. Never bothered to report it until Distribute 0.6.1 was released which Tarek fixed in less than a week. I never bothered to report it for setuptools as I know it isn't maintained. It's probably in our best interest to just get people over to Distribute, let it continue to hijack setuptools, and slowly let that name fade out if it is going to continue to be unmaintained. I have to admit I find it really disheartening that we are letting an unmaintained project dictate how we fix a bug. I really hope this is a one-time deal and from this point forward we all move the community towards Distribute so we never feel pressured like this again. Even though the bug was noticed, nobody thought that, just perhaps, breaking other software in a minor point release might be a bad idea, no matter whether it was updated in less-than-a-week, or mostly- unmaintained? Once you have an API that you encourage people to subclass, *of course* it dictates how you can fix a bug. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Package install failures in 2.6.3
My question was less about the political aspects than the technical aspects. I gather you're saying that the fix to setuptools will make it work in 2.6.3 without inadvertently breaking it for 2.6.2, 2.6.1, and 2.6.0, right? Have you tried the fix in those older versions to be sure? If, as I hope, the answer to that is yes, then I strongly support releasing a fixed setuptools instead of reverting the change to Python. Yes it does. The fix makes sure build_ext.get_ext_filename still works as it is supposed (just returning the extension of a filename depending on the environment) under all versions, I don't think this is factually correct. I assume you talk about distribute change e07e5309cd2a, right? While that change arranges to always return a result when called with an unqualified module name, it doesn't do the additional computation that setuptools does in that case, which may give something different in case the extension is a Library or in case _links_to_dynamic is true. So I would rather expect that distribute is now broken in these cases (which are seemingly rare, though). It's two lines in Setuptools. But that change may be incorrect. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
