Re: [Distutils] Packaging situation + mailing list rules
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad.
I'm not mad at it being provided with a compatible API. However, I *am* very unhappy with the fact that the version of distribute that's being shipped with OS distributions is both packaged as (e.g.) "python-setuptools", AND prevents people from installing the real setuptools, even in a local directory! So, David, I hope you've filed this as a bug report with both Distribute and Ubuntu, and that others will do the same for any other distribution that's shipping distribute under a misleading name and that has this behavior. My understanding when this was discussed previously, was that distribute would *only* suppress the installation of setuptools versions released *before* the corresponding version of distribute. Also, considering how widespread the "setuptools isn't being maintained" lie is at this point, I'm a bit concerned that some OS distributors may have been unduly influenced by it in their switching decisions. My understanding (and I would guess, that of the OS distributors' as well) was *also* based on the premise that distribute was going to track with setuptools' feature additions and bug fixes, which it clearly has not. The 0.6c11 release (last October) fixed a rather long list of bugs besides the one you reported; does anyone know if the rest are actually fixed in Distribute?
On Sun, Jul 4, 2010 at 3:03 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad.
I'm not mad at it being provided with a compatible API.
This is obviously fine.
However, I *am* very unhappy with the fact that the version of distribute that's being shipped with OS distributions is both packaged as (e.g.) "python-setuptools", AND prevents people from installing the real setuptools, even in a local directory!
So, David, I hope you've filed this as a bug report with both Distribute and Ubuntu, and that others will do the same for any other distribution that's shipping distribute under a misleading name and that has this behavior.
Barry did it for ubuntu, zooko did a few months ago for distribute and I provided the patch for distribute (a few months ago as well). But I did not realize a few months ago that I was forced to use distribute without any fallback. On the bright side, this gave me much more respect for you and setuptools, and I admire your patience. David
On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad.
I'm not mad at it being provided with a compatible API. However, I *am* very unhappy with the fact that the version of distribute that's being shipped with OS distributions is both packaged as (e.g.) "python-setuptools", AND prevents people from installing the real setuptools, even in a local directory!
That's not the intent. You can install setuptools if you want, globally, by removing distribute. You can install also a local setuptools. If you can't do it, and your issue is not in #143, you can fill a bug in the distribute tracker.
So, David, I hope you've filed this as a bug report with both Distribute and Ubuntu, and that others will do the same for any other distribution that's shipping distribute under a misleading name and that has this behavior.
This is now fixed in distribute and is getting fixed in distributions that use distribute, because we work TOGETHER.
My understanding when this was discussed previously, was that distribute would *only* suppress the installation of setuptools versions released *before* the corresponding version of distribute.
Also, considering how widespread the "setuptools isn't being maintained" lie is at this point, I'm a bit concerned that some OS distributors may have been unduly influenced by it in their switching decisions.
Setuptools has not been maintained over the last two years. You just have made a few changes lately, in reaction of the fork. Don't worry about the OS distributors, they are aware of the situation/ Again, a simple svn log in your repository when the fork happened and when OS distributions have switched, is enough to see that setuptools was not maintained. If you are back on track and want to maintain it again, great ! maybe the fork will dissapear, for the very same reason it appeared: to avoid being locked by your 'glacial pace' (that's your words)
My understanding (and I would guess, that of the OS distributors' as well) was *also* based on the premise that distribute was going to track with setuptools' feature additions and bug fixes, which it clearly has not. The 0.6c11 release (last October) fixed a rather long list of bugs besides the one you reported; does anyone know if the rest are actually fixed in Distribute?
I have tracked that one single huge commit, and tried to backport everything. Obvisouly I missed something,. But I will double check again before I release 0.6.14, to avoid any flames here.
On Sun, Jul 4, 2010 at 3:30 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad.
I'm not mad at it being provided with a compatible API. However, I *am* very unhappy with the fact that the version of distribute that's being shipped with OS distributions is both packaged as (e.g.) "python-setuptools", AND prevents people from installing the real setuptools, even in a local directory!
That's not the intent. You can install setuptools if you want, globally, by removing distribute.
Right, because remove python-setuptools (which is distribute) is not impractical at all on ubuntu. David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad. I'm not mad at it being provided with a compatible API. However, I *am* very unhappy with the fact that the version of distribute that's being shipped with OS distributions is both packaged as (e.g.) "python-setuptools", AND prevents people from installing the real setuptools, even in a local directory!
That's not the intent. You can install setuptools if you want, globally, by removing distribute. You can install also a local setuptools.
If you can't do it, and your issue is not in #143, you can fill a bug in the distribute tracker.
So, David, I hope you've filed this as a bug report with both Distribute and Ubuntu, and that others will do the same for any other distribution that's shipping distribute under a misleading name and that has this behavior.
This is now fixed in distribute and is getting fixed in distributions that use distribute, because we work TOGETHER.
My understanding when this was discussed previously, was that distribute would *only* suppress the installation of setuptools versions released *before* the corresponding version of distribute.
Also, considering how widespread the "setuptools isn't being maintained" lie is at this point, I'm a bit concerned that some OS distributors may have been unduly influenced by it in their switching decisions.
Setuptools has not been maintained over the last two years. You just have made a few changes lately, in reaction of the fork. Don't worry about the OS distributors, they are aware of the situation/
Again, a simple svn log in your repository when the fork happened and when OS distributions have switched, is enough to see that setuptools was not maintained.
If you are back on track and want to maintain it again, great ! maybe the fork will dissapear, for the very same reason it appeared: to avoid being locked by your 'glacial pace' (that's your words)
My understanding (and I would guess, that of the OS distributors' as well) was *also* based on the premise that distribute was going to track with setuptools' feature additions and bug fixes, which it clearly has not. The 0.6c11 release (last October) fixed a rather long list of bugs besides the one you reported; does anyone know if the rest are actually fixed in Distribute?
I have tracked that one single huge commit, and tried to backport everything. Obvisouly I missed something,. But I will double check again before I release 0.6.14, to avoid any flames here.
In that spirit, Tarek, you need to stop saying "setuptools is unmaintained for the last 2 years": PJE objects to it as unfactual, as do I. THe release last October makes that statement untrue on its face. Please note as well that nothing about this is criticism of the choice to fork, or any work you and others have done on distrbute, the PEPs, distutils2, etc. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwvjjEACgkQ+gerLs4ltQ7CDACcDhcinnL2WzzH75KIeQrmNFcB sg0An205oYtcSFH+eTh0h3craZTgcpgo =9zjC -----END PGP SIGNATURE-----
At 03:23 PM 7/3/2010 -0400, Tres Seaver wrote:
In that spirit, Tarek, you need to stop saying "setuptools is unmaintained for the last 2 years": PJE objects to it as unfactual, as do I. THe release last October makes that statement untrue on its face.
Additionally, I would like to have some reassurance that when I begin releasing 0.7 alpha versions, that the distribute community is not going to start accusing me (as Tarek just did) of doing things "in reaction" to them, or to sabotage them, or say that I'm trying to force people to switch back to setuptools... And ideally, I would like them to refrain from implementing technological measures to interfere with setuptools' normal upgrade process. Since last September, the current release of setuptools has been downloaded from PyPI more times than all releases of distribute *combined*. I am therefore much more concerned with providing normal updates to the setuptools user base, than I am with interfering with people who really *want* to use distribute, for whatever reason. However, by the same token, it also means that I have no wish to spend a lot of time trying to figure out how to work *around* distribute! I would much prefer to advise people who wish to upgrade setuptools, to simply uninstall distribute before upgrading, rather than to have to implement technological measures to address the situation. But the last time that I advised that people upgrading setuptools needed to uninstall distribute first, I received accusations that I was trying to undermine distribute and spread FUD by telling people to uninstall it. (My time for working on open source development these days is limited, and tends to come in chunks, especially around holidays. There were at least two such opportunities earlier this year where I considered tackling some of my smaller planned features for 0.7, and then thought about the likely hassle of actually *releasing* any of that work, and then promptly turned my attention to other, less-controversial projects.)
I don't want to be inflammatory, but I am a user of setuptools and distribute and I think I have a valid concern that this list should note. The fact that Debian and Ubuntu made the "python-setuptools" .deb install Distribute instead of setuptools, and that Distribute has some bugs that setuptools doesn't, has caused major headaches for me who is trying to distribute some software and wants it to work on Debian and Ubuntu as well as other platforms. https://bitbucket.org/tarek/distribute/issue/142/easy_install-will-install-a... Oh, look! Two days ago Tarek wrote a unit test for my problem! Joy! (Dear Tarek: I'm sorry I never wrote that unit test. Now you don't have to wear a Tahoe-LAFS t-shirt.) So, just to be clear: I'm not contributing to this discussion to say that the Distribute project or Tarek are bad, or that they are worse than the Setuptools project or PJE. (Indeed, the fact that Tarek has written a unit test for this bug is very, very good.) But I *am* saying that swapping in a large, complicated, buggy piece of software as a replacement for another large, complicated, buggy piece of software is a sensitive operation that should only be done with care and with a good plan to revert to the earlier version. The fact that Debian and Ubuntu did this without informing their users and without providing any way to undo this (within the context of the Debian/Ubuntu packaging system) is a major bungle. I plead with the members of this list: 1. Please respect the fact that some of your users will sometimes employ another tool than the tool you are working on. They have their own reasons, even if it is only "The Devil (bugs) you know is better than the Devil (bugs) you don't know.". They may have values or preferences that you don't understand or don't share. Just be respectful in word and in deed. 2. Be extremely careful when automating such disruptive changes. Please provide documentation warning users about the change and a method to revert. This is primarily the job of Debian/Ubuntu in this case, of course, but distutils-sig and python-dev can probably help by making it clear to everyone that distribute and setuptools are two separate, actively developed tools with different strengths and weaknesses. 3. If you are positioning your tool as an "upgrade" or a "drop-in replacement" then any regression that a user experiences when they upgrade is a high-priority issue. Even if Tarek's unit test is right and the bug fix fixes my problems, then I have to try to get Ubuntu to patch their version of Distribute which they ship in Ubuntu 10.04 Lucid and then wait for my users to upgrade. Some step in that chain is probably not going to work for all users, so I will probably be having to work-around this problem for years to come. In addition, I have had to change the source code of my own tools to include work-arounds for this bug, so now I will be supporting my own work-arounds for months or years. Thanks for listening, folks. I hope we as a community will make it easier for people to use these tools in the future. The vast majority of the users are probably completely unaware of the flamewars on this list, and that's for the best. :-) Hopefully they will eventually get better tools and release processes from us and they will be grateful. Regards, Zooko
On Sun, Jul 4, 2010 at 3:03 AM, P.J. Eby <pje@telecommunity.com> wrote:
My understanding (and I would guess, that of the OS distributors' as well) was *also* based on the premise that distribute was going to track with setuptools' feature additions and bug fixes, which it clearly has not. The 0.6c11 release (last October) fixed a rather long list of bugs besides the one you reported; does anyone know if the rest are actually fixed in Distribute?
There is another potential issue with the edit mode, but I have not been able to track it down yet, and as such have not reported it (nor checked if it was already reported). Basically, easy_install -eNb somedir somepackage does not always work, with some strange error. I cannot always reproduce it. David
participants (5)
-
David Cournapeau -
P.J. Eby -
Tarek Ziadé -
Tres Seaver -
Zooko O'Whielacronx