Package install failures in 2.6.3 - setuptools vs Distribute
I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic: File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree' http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard Appscript is another package that fails similarly. There must be others. I don't know what's to be done about this awkward incompatibility now that 2.6.3 is out the door other than perhaps making sure maintainers of affected packages are aware of what their users are running into and can update their documentation. There is one small thing that may help some users who find their way to http://pypi.python.org/pypi/distribute. OS X, for one, does not ship with wget however it does have curl. Suggest adding another example: $ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py -- Ned Deily, nad@acm.org
2009/10/3 Ned Deily <nad@acm.org>:
I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic:
File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree'
http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard
Appscript is another package that fails similarly. There must be others.
I can confirm this. It seems to be packages that use c-extensions. zope.interface also breaks.
$ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py
Distribute doesn't break, though, so "sudo easy_install Distribute" seems to be enough. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Sat, Oct 3, 2009 at 2:15 PM, Lennart Regebro <regebro@gmail.com> wrote:
2009/10/3 Ned Deily <nad@acm.org>:
I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic:
File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree'
http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard
Appscript is another package that fails similarly. There must be others.
I can confirm this. It seems to be packages that use c-extensions. zope.interface also breaks.
Yes Setuptools makes some assumptions on how distutils APIs are called and in which order. Once bitbucket is up, you can look at the details on the fix I did, it's fairly simple. Notice that this has been fixed in Ubuntu already with a patched version of setuptools, but the next probable step is to use Distribute there and in debian.
$ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py
Distribute doesn't break, though, so "sudo easy_install Distribute" seems to be enough. :-)
Yes that's the simplest way to fix the problem. Notice that setuptools patches distutils in other places, and it will not work with Python 2.7 and 3.2 where Distribute does. Cheers Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
In article <94bdd2610910030649r431a5638y7c8b5332934f5ae@mail.gmail.com>, Tarek Ziad? <ziade.tarek@gmail.com> wrote:
On Sat, Oct 3, 2009 at 2:15 PM, Lennart Regebro <regebro@gmail.com> wrote:
2009/10/3 Ned Deily <nad@acm.org>:
I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic:
File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree'
http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard
Appscript is another package that fails similarly. There must be others.
I can confirm this. It seems to be packages that use c-extensions. zope.interface also breaks.
Yes Setuptools makes some assumptions on how distutils APIs are called and in which order. Once bitbucket is up, you can look at the details on the fix I did, it's fairly simple.
Notice that this has been fixed in Ubuntu already with a patched version of setuptools, but the next probable step is to use Distribute there and in debian.
That's fine but how does this help users on OS X, for example, when the python 2.6.3 they are using is supplied only by the python.org installers? And the maintainers of the packages that can't be installed?
$ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py
Distribute doesn't break, though, so "sudo easy_install Distribute" seems to be enough. :-) Yes that's the simplest way to fix the problem.
But that's assuming they have a working easy_install installed for *that* version (2.6.3) in the first place. For instance, the OS X installer does not include setuptools or Distribute. I'm concerned about users who just want to install some third-party package for the first time. They try to follow the recipe for bootstrapping Distribute and fail right at the first step because they don't have wget on their system (for example, OS X) and they don't know what it is. Getting it right for beginners is one of the reasons why easy_install was developed in the first place.
Notice that setuptools patches distutils in other places, and it will not work with Python 2.7 and 3.2 where Distribute does.
That's fine, too, and there are lessons to be learned here, I think, that should influence 2.7 and 3.2. But the big problem is distutils in 2.6.3. This is not trying to debate the Distribute fork; the target audience for easy_install doesn't care one way or the other. More importantly, they haven't a clue that there is something called Distribute and they don't know what setuptools is. Like it or not, easy_install / setuptools is a major customer of distutils and somehow it got broken for 2.6.3, a point release. From the end user and the 3rd-party packagers' points of view: the 3rd-party package didn't change, setuptools didn't change (obviously!), but now the package won't install and, worse, fails cryptically. So the problem must be Python - so they think and with some justification, it seems. Once they get Distribute installed, everything should be fine but how do they know they are supposed to install Distribute? This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away. -- Ned Deily, nad@acm.org
2009/10/3 Ned Deily <nad@acm.org>:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away.
It's unfortunate that this comes in a minor release. But at the same time we can hardly avoid fixing bugs just because setuptools isn't getting updated at the moment. It's a lose-lose situation. As I see it this will speed up adaptation of Distribute. Word will spread. It's not ideal, but then it's not a perfect world. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Oct 3, 2009, at 4:08 PM, Lennart Regebro wrote:
2009/10/3 Ned Deily <nad@acm.org>:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away.
How about some sort of an announcement/warning on the setuptools site itself? I know the code's not going to get updated but how about a simple warning and suggestion to move on to Distribute? S
Lennart Regebro wrote:
2009/10/3 Ned Deily <nad@acm.org>:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away.
It's unfortunate that this comes in a minor release.
Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.
But at the same time we can hardly avoid fixing bugs just because setuptools isn't getting updated at the moment. It's a lose-lose situation.
Setuptools is hardly a minor software tool. Considering that setuptools is a major focus and key technology of this group, those making changes to distutils should have tested against setuptools and devised a solution providing backward compatibility, along with deprecation warnings. Lennart and Tarek, I know you at least are familiar with this valuable practice in Zope for years. At the least, those making changes to Distutils should, after testing against Setuptools, widely announced this was coming. It does not reflect positively on the Distribute team and even hints of under-the-table intentionality in forcing the community to abandon use of setuptools. Distribute should win because of superior technology not forced migration.
As I see it this will speed up adaptation of Distribute. Word will spread. It's not ideal, but then it's not a perfect world.
Distribute is very new and there are many folk who will not be adopting it until it has been out for quite some time. It is a fact of the conservative nature of some development teams. If setuptools were an optional, little-used technology in Python it would not be a big deal but it isn't. It is not appropriate to -force- users to adopt a particular branch of a fork, except perhaps in the move from Python 2.x to 3.x where major changes are anticipated and there was no setuptools for 3.x anyway. Considering that 2.6.3 is messed up in other ways, like displaying the SVN rc1 tag and a broken logging module, and probably will be re-released at 2.6.4 very shortly, perhaps we can get this -at least- into the Python docs and maybe introduce backward compatible hooks into distutils to support setuptools. -Jeff
2009/10/5 Jeff Rush <jeff@taupro.com>:
Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.
Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. But yes, it was discovered before release, and maybe it should have been discussed, I'm not on python-dev anymore.
and even hints of under-the-table intentionality in forcing the community to abandon use of setuptools.
There are no such hints anywhere.
Distribute should win because of superior technology not forced migration.
That makes no sense. You move to distribute because you have to, because setuptools is buggy and not updated. Until people encounter bugs in setuptools, or need Python 3 support, they are not likely to move to Distribute. There is no other reason than forced migration. Also, there is no "win" or "lose". This is not a competition.
Distribute is very new and there are many folk who will not be adopting it until it has been out for quite some time.
Nobody will adopt it until they are forced to. This unfortunate bug means people are forced to quicker than expected. I don't think that's an actual problem.
It is a fact of the conservative nature of some development teams.
Conservative development teams are not likely to either use Subversion 1.6 or Python 2.6.3, so they are not affected by any of the major setuptools problems. I would have expected people starting to get forced to Distribute when major distros where shipping with subversion 1.6. Now it's going to be when they ship with Python 2.6.3 instead. I fail to see how this is a big disaster in any way. Yes, it's not perfect, and yeah, maybe there should have been big warning signs somewhere. But we can NOT leave bugs in Python just because setuptools isn't getting updated. Setuptools has already been a break on Python 3 development, are we gonna lets it be a break on Python 2 bugfixes too? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
2009/10/5 Jeff Rush <jeff@taupro.com>:
Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.
Well "this major"... It's a bug fix that breaks a setuptools monkey-patch. But yes, it was discovered before release, and maybe it should have been discussed, I'm not on python-dev anymore.
The fact that the bugfix (to distutils) was committed by folks who are *alos* pusing a fork to setuptools is what raises the eyebrows here. Note that I am *not* suggesting that anyone acted in bad faith; but the "appearance of impropriety" can be present where no actual impropriety exists. The only cure is for the "conflicted" parties to take extreme measures to avoid appearing to act improperly.
and even hints of under-the-table intentionality in forcing the community to abandon use of setuptools.
There are no such hints anywhere.
There are those postig on this thread that the distutils breakage is a good thing for Distribute, because it *forces* folks to switch: I call that a solid hint, myself.
Distribute should win because of superior technology not forced migration.
That makes no sense. You move to distribute because you have to, because setuptools is buggy and not updated. Until people encounter bugs in setuptools, or need Python 3 support, they are not likely to move to Distribute. There is no other reason than forced migration.
But you shouldn't have to move to Distribute becuase the Distrubute developers broke setuptools by changing the Python stdlib (intentionally or not). <snip>
I fail to see how this is a big disaster in any way. Yes, it's not perfect, and yeah, maybe there should have been big warning signs somewhere. But we can NOT leave bugs in Python just because setuptools isn't getting updated. Setuptools has already been a break on Python 3 development, are we gonna lets it be a break on Python 2 bugfixes too?
Bugfixes which break backward compatibility in "minor" relaseses are "major" fouls, period. As PJE points out, the particular bugfix in question *also* broke other packages (pywin32), which means that it can't be just that setuptools is "unmaintained" (I'm not supposed to have to re-relase my packages to cope with a patch-level release in Python, period). 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 iEYEARECAAYFAkrMDJcACgkQ+gerLs4ltQ5KxQCg0yhegMhrML5bv7xniRfngG8j FFMAnjmPsBHXZW3sc4/M/qx3N+x1ura2 =2gq3 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Bugfixes which break backward compatibility in "minor" relaseses are "major" fouls, period.
Sure, but what does backward compatibility even mean for distutils ? Not much, as any non trivial extension needs to use undocumented implementation details.
As PJE points out, the particular bugfix in question *also* broke other packages (pywin32), which means that it can't be just that setuptools is "unmaintained"
No, it is a consequence of distutils design and implementation. I think those breakages are unavoidable if you touch distutils besides trivial bug fixes (and the list of trivial things you can do to distutils without breaking anything is tiny). I already had to adapt numpy.distutils numerous times when distutils changed, so I don't think it is fair to point this particular issue as a major foul. It should be accepted that people relying on distutils internals (that is almost anybody using distutils extensions, especially for compiled code) will have to constantly change their code IMHO. cheers, David
2009/10/7 Tres Seaver <tseaver@palladion.com>:
The fact that the bugfix (to distutils) was committed by folks who are *alos* pusing a fork to setuptools is what raises the eyebrows here.
Eh... why? Tarek has become the lead for Python packaging programs and is trying hard to fix the sad state of Python packaging. It's not particularily surprising that he (or otehrs involved in Python packaging) would be involved in more than one package.
Note that I am *not* suggesting that anyone acted in bad faith; but the "appearance of impropriety" can be present where no actual impropriety exists. The only cure is for the "conflicted" parties to take extreme measures to avoid appearing to act improperly. ... There are those postig on this thread that the distutils breakage is a good thing for Distribute, because it *forces* folks to switch: I call that a solid hint, myself.
I'm sorry, but I read this as you implying that somebody could think Tarek, me and other Distribute people is involved in some sort of Python packaging conspiracy. I can't take that seriously, so I really hope that you mean something else, because that idea is just laughable. There is no appearance of impropriety. There is no "conflicted party". There is no conflict. You can't read anything as being good for Distribute, because there is no "good for Distribute". Distribute does not benefit from people using it. People benefit from using Distribute. I suspect that you see some conflict or competition between Distribute and setuptools when there is none. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
In article <4AC9BEF5.7080204@taupro.com>, Jeff Rush <jeff@taupro.com> wrote:
2009/10/3 Ned Deily <nad@acm.org>:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away.
It's unfortunate that this comes in a minor release. Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the
Lennart Regebro wrote: python-committers list of something this major.
But at the same time we can hardly avoid fixing bugs just because setuptools isn't getting updated at the moment. It's a lose-lose situation. Setuptools is hardly a minor software tool. Considering that setuptools is a major focus and key technology of this group, those making changes to distutils should have tested against setuptools and devised a solution providing backward compatibility, along with deprecation warnings. Lennart and Tarek, I know you at least are familiar with this valuable practice in Zope for years.
At the least, those making changes to Distutils should, after testing against Setuptools, widely announced this was coming. It does not reflect positively on the Distribute team and even hints of under-the-table intentionality in forcing the community to abandon use of setuptools. Distribute should win because of superior technology not forced migration.
As I see it this will speed up adaptation of Distribute. Word will spread. It's not ideal, but then it's not a perfect world.
Distribute is very new and there are many folk who will not be adopting it until it has been out for quite some time. It is a fact of the conservative nature of some development teams. If setuptools were an optional, little-used technology in Python it would not be a big deal but it isn't. It is not appropriate to -force- users to adopt a particular branch of a fork, except perhaps in the move from Python 2.x to 3.x where major changes are anticipated and there was no setuptools for 3.x anyway.
Just another data point: the MacPorts distrbution has just upgraded their python26 to 2.6.3 and now a number of their py26 packages can't be installed because they use setuptools (or depend on another package that uses setuptools) to build C extensions and those fail due to the change in distutils: among others, ipython, numpy, pyobjc2, twisted. Until the MacPorts folks recognize and push out a fix, using the setuptools easy_install to install distribute works - if you know the trick.
Considering that 2.6.3 is messed up in other ways, like displaying the SVN rc1 tag and a broken logging module, and probably will be re-released at 2.6.4 very shortly, perhaps we can get this -at least- into the Python docs and maybe introduce backward compatible hooks into distutils to support setuptools.
I've opened an issue of the main Python issue tracker outlining the problem, primarily for the benefit of affected users who search the tracker: http://bugs.python.org/issue7064 -- Ned Deily, nad@acm.org
On Mon, Oct 5, 2009 at 1:33 PM, Ned Deily <nad@acm.org> wrote:
I've opened an issue of the main Python issue tracker outlining the problem, primarily for the benefit of affected users who search the tracker:
If I understand the comments on this ticket correctly, Tarek has changed distutils in a way so the last setuptools release continues to work, correct? So based on the current state of Python 2.6.4 will work again with an unmodified setuptools 0.6c9? Hanno
On Oct 5, 2009, at 5:40 AM, Jeff Rush wrote:
Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.
[...]
Considering that 2.6.3 is messed up in other ways, like displaying the SVN rc1 tag and a broken logging module, and probably will be re-released at 2.6.4 very shortly, perhaps we can get this -at least- into the Python docs and maybe introduce backward compatible hooks into distutils to support setuptools.
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4. -Barry
On Monday,2009-10-05, at 7:38 , Barry Warsaw wrote:
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4.
Why not move ahead with both? Then, for example, people who do have Python 2.6.3 installed and get the latest setuptools will be okay, and also people who have setuptools-0.6c9 installed and get the latest Python. There are a lot of people who have constraints on what they they can deploy and when, so it wouldn't hurt to have both fixes available. (Also, one of the fixes might not get done in a timely way.) Thanks, Zooko
On Mon, Oct 5, 2009 at 4:02 PM, Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
On Monday,2009-10-05, at 7:38 , Barry Warsaw wrote:
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4.
Why not move ahead with both? Then, for example, people who do have Python 2.6.3 installed and get the latest setuptools will be okay, and also people who have setuptools-0.6c9 installed and get the latest Python. There are a lot of people who have constraints on what they they can deploy and when, so it wouldn't hurt to have both fixes available.
So are you saying that in an environment where you are allowed to install Python 2.6.3, you will not be allowed to install an hypothetical setuptools-0.6c10 (or a Distribute 0.6.3) ? Tarek
On Monday,2009-10-05, at 8:11 , Tarek Ziadé wrote:
So are you saying that in an environment where you are allowed to install Python 2.6.3, you will not be allowed to install an hypothetical setuptools-0.6c10 (or a Distribute 0.6.3) ?
Yes, situations like that can come up. For example, I guess the packaging of my own Tahoe-LAFS project is a case in point. The current requirements for Tahoe-LAFS are Python >= 2.4.2 and < 3.0, and the source distribution of Tahoe-LAFS comes with its own bundled copy of setuptools. We haven't finished our qualification of Distribute so we're not ready to switch our build system to Distribute. Setuptools-0.6c10 is hypothetical at this point. What do we do? We could tighten the Python version to >= 2.4.2 and <= 2.6.2. We could develop and test a patch to our bundled copy of setuptools to work-around this problem. We could ask the open source volunteer who is testing Distribute for us to "hurry up". We could ask PJE to "hurry up" and release a new version of setuptools. Perhaps we will end up doing more than one of these things. Many of our users won't even be able to diagnose the problem if they upgrade from Python 2.6.2 to 2.6.3 and the install breaks. They won't know what is wrong or how to work around it, other than by writing to our mailing list asking for help. The faster this gets fixed and the more "lenient" Python 2.6.x is with respect to what versions of setuptools/Distribute it requires and the more "lenient" setuptools and Distribute are with respect to what version of Python they require, the better for everyone. Thank you kindly for your attention. Regards, Zooko
I'm sorry to follow-up to my own post, but I realized that I didn't make something clear: the current Tahoe-LAFS source distribution comes with its own copy of setuptools, so even if PJE releases a new version of setuptools or if we patch that copy to work-around this problem, we're going to have to re-qualify the combination of the new version on our buildbot and make a new stable release of Tahoe-LAFS (something that typically only happens every 3 or 4 months) before end users will be able to install Tahoe-LAFS on Python 2.6.3. I don't want to point fingers, because that goes nowhere. Lots of people could have written their software or managed their processes differently in order to avoid this situation, including me. However, I do want to emphasize that this is a serious problem. Backwards compatibility on minor releases such as from 2.6.2 to 2.6.3 is a huge concern for a lot of people. If something like this breaks -- regardless of whose fault(s) it is -- then it reduces people's trust in the stability of stable updates of their infrastructural software. I'm sorry to say that this event has already made me more hesitant to jump from setuptools to Distribute, just because some of the maintainers of Distribute have posted saying that they don't think this kind of thing is such a big deal. I prefer to use packaging tools which are stable. To achieve that kind of stability sometimes requires basically "taking responsibility" for other people's decisions, such as saying "Well, setuptools-0.6c9 monkey-patches distutils. We think that's a bad idea and we wish it didn't do that. But, we know that a lot of other people out there are relying on the combination of setuptools-0.6c9 and Python 2.6.x, so we're going to go the extra mile to make sure that those people don't experience disruptions.". Please take this in the constructive spirit that is intended. We're on the same team. I've already contributed a few patches and a lot of bug reports to setuptools, Distribute, and Python, and I'd like to contribute more in the future. Having a policy of actively working to maintain stability across stable updates will help everyone. Regards, Zooko
2009/10/5 Zooko Wilcox-O'Hearn <zooko@zooko.com>:
I'm sorry to say that this event has already made me more hesitant to jump from setuptools to Distribute, just because some of the maintainers of Distribute have posted saying that they don't think this kind of thing is such a big deal. I prefer to use packaging tools which are stable.
You completely misunderstand. It's not that it isn't a big deal that setuptools isn't maintained. It *is* a big deal. But that you are forced to upgrade *now* is not a big deal, because you would be forced to upgrade soon any way. What you seem to miss in this whole discussion is that setuptools is buggy, and unmaintained, and that you will have to move from setuptools sooner or later. That setuptools is broken *is* a big deal. That is an effect of the current situation, and as you know that is a situation only one person can do anything about. BUT: It is *not* a big deal that this breakage affects you today, instead of in six months. I understand that maybe for you, of there had been more warnings, you could have had time to move to Distribute, and thereby move to 2.6.3 already now, instead of having to wait a bit. But then again, you are not only in a very special and unusual situation, you already use a patched version of setuptools (presumably because of it's unmaintaned state) and you can therefore easily apply this patch to your copy, and therefore be up and running again. For everyone else, who does not have the strict rules you do, the fix is easy. All they need to do is "easy_install Distribut" and it will work again. That is *not* a big deal. That bugs in setuptools make you reluctant to migrate to Distribute is a position I must admit I don't understand. Possibly if you somehow think it's the Distribute teams fault that a bugfix in Python ended up breaking setuptools. If it would have been better not to fix that bug, then the blame reasonably goes to the Python core developers, not the Distribute team. Once again, to make things completely clear: The breakage *is* a big deal. That it happens to break today instead of tomorrow is not. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
I'm struggling to articulate something here. When the maintainer of the stable branch of a platform that I rely on says "The fact that upgrading to our recent stable release will break this critical functionality is so-and-so's fault, not ours." this reduces my confidence in that maintainer. Not because he's wrong! Maybe it *is* so-and-so's fault. But what I'm looking for in the maintainer of a stable platform is someone who says "Maybe this wasn't our fault, but here are the steps we're taking to get you back on your feet as soon as possible.". Regards, Zooko
Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
I'm struggling to articulate something here. When the maintainer of the stable branch of a platform that I rely on says "The fact that upgrading to our recent stable release will break this critical functionality is so-and-so's fault, not ours." this reduces my confidence in that maintainer. Not because he's wrong! Maybe it *is* so-and-so's fault. But what I'm looking for in the maintainer of a stable platform is someone who says "Maybe this wasn't our fault, but here are the steps we're taking to get you back on your feet as soon as possible.".
Zooko, I've struggled with this over the last year, in integrating a dozen fairly complicated third-party Python extensions for my system. I've come to the conclusion that the problem is setuptools, and I'm trying hard to remove it entirely from my system. I have no problem with the .egg format or the basic idea, or even the implementation, which I think is pretty nice. It's the structure of the setuptools project that gives me pause. There seems to be one developer, and he seems to be too busy to fix the well-known bugs (like having easy_install ruin the sys.path settings by putting stuff on it in the wrong place -- is that one fixed yet?). In addition, I think the mere existence of setuptools stifles progress on distutils, which is where all the clever tricks of setuptools should properly appear. This would let the whole community of Python developers work on the codebase. I'd like to see a flag on PyPI marking whether the package relies on setuptools, in which case I'll avoid it, or voluntarily entangles itself with setuptools if present (as the only known way to create eggs), or is setuptools-free (my preferred configuration). Frankly, I'd also recommend putting up a warning to developers on PyPI noting these problems with setuptools. Bill
Bill Janssen kirjoitti:
Zooko Wilcox-O'Hearn <zooko@zooko.com> wrote:
I'm struggling to articulate something here. When the maintainer of the stable branch of a platform that I rely on says "The fact that upgrading to our recent stable release will break this critical functionality is so-and-so's fault, not ours." this reduces my confidence in that maintainer. Not because he's wrong! Maybe it *is* so-and-so's fault. But what I'm looking for in the maintainer of a stable platform is someone who says "Maybe this wasn't our fault, but here are the steps we're taking to get you back on your feet as soon as possible.".
Zooko, I've struggled with this over the last year, in integrating a dozen fairly complicated third-party Python extensions for my system.
I've come to the conclusion that the problem is setuptools, and I'm trying hard to remove it entirely from my system.
I have no problem with the .egg format or the basic idea, or even the implementation, which I think is pretty nice. It's the structure of the setuptools project that gives me pause. There seems to be one developer, and he seems to be too busy to fix the well-known bugs (like having easy_install ruin the sys.path settings by putting stuff on it in the wrong place -- is that one fixed yet?).
In addition, I think the mere existence of setuptools stifles progress on distutils, which is where all the clever tricks of setuptools should properly appear. This would let the whole community of Python developers work on the codebase.
I'd like to see a flag on PyPI marking whether the package relies on setuptools, in which case I'll avoid it, or voluntarily entangles itself with setuptools if present (as the only known way to create eggs), or is setuptools-free (my preferred configuration). Frankly, I'd also recommend putting up a warning to developers on PyPI noting these problems with setuptools.
Does your bug still exist in Distribute? If so, please report it at http://bitbucket.org/tarek/distribute/ (assuming that bitbucket is operational, which it currently isn't)
Bill _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Alex Grönholm <alex.gronholm@nextday.fi> wrote:
Does your bug still exist in Distribute? If so, please report it at http://bitbucket.org/tarek/distribute/ (assuming that bitbucket is operational, which it currently isn't)
Sorry, Alex, I don't know about Distribute, don't (particularly) care. If you care, test for it and report it if it's there. It's bug 53 in the setuptools bug reporter. Bill
Bill Janssen kirjoitti:
Alex Grönholm <alex.gronholm@nextday.fi> wrote:
Does your bug still exist in Distribute? If so, please report it at http://bitbucket.org/tarek/distribute/ (assuming that bitbucket is operational, which it currently isn't)
Sorry, Alex, I don't know about Distribute, don't (particularly) care. If you care, test for it and report it if it's there. It's bug 53 in the setuptools bug reporter.
Bill
If you are seriously expecting setuptools to be fixed, I can only assume you haven't been following the conversation on this list.
On Mon, Oct 5, 2009 at 3:38 PM, Barry Warsaw <barry@python.org> wrote:
On Oct 5, 2009, at 5:40 AM, Jeff Rush wrote:
Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.
[...]
Considering that 2.6.3 is messed up in other ways, like displaying the SVN rc1 tag and a broken logging module, and probably will be re-released at 2.6.4 very shortly, perhaps we can get this -at least- into the Python docs and maybe introduce backward compatible hooks into distutils to support setuptools.
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. If that's not possible, then we might need to revert the distutils 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 -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On Oct 5, 2009, at 9:38 AM, Barry Warsaw wrote:
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4.
I thought the whole point of the Distribute project was that we couldn't _get_ a new setuptools release and, so, had to fork. Hopefully, with this motivation, we'll get a new setuptools "one more time!" and make the transition to Distribute a little more controlled. Fast, but controlled. S
2009/10/5 Barry Warsaw <barry@python.org>:
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap.
PJE seems interested in this, as he asked about a patch, so maybe.
If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4.
That would be a big mistake. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Oct 5, 2009 at 4:57 PM, Lennart Regebro <regebro@gmail.com> wrote:
2009/10/5 Barry Warsaw <barry@python.org>:
I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap.
PJE seems interested in this, as he asked about a patch, so maybe.
It was pushed in setuptools bug tracker by Ned yesterday IIRC, with links to the patch that works.
On Sat, Oct 3, 2009 at 7:00 PM, Ned Deily <nad@acm.org> wrote:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away.
Make sure to understand that the way setuptools patches distutils makes it very sensible to any change made in distutils, even backward compatibles ones like in the 2.6 branch. But I won't freeze distutils work because of that, and distutils is not to be blamed if setuptools is broken, neither Python. Especially for a project that has not been maintained for over a year... So it's not a good experience for the users that's true, and we can try to enhance the Distribute documentation to help them as you suggested, and we are already helping because we've forked to try to provide some solutions. But there's nothing else I can think of to help people. My advice would be that the projects that use setuptools just switch asap on distribute, which is actively maintained.
-- Ned Deily, nad@acm.org
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
In article <94bdd2610910031309w61d72dcdo8faab4964bf67551@mail.gmail.com>, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Sat, Oct 3, 2009 at 7:00 PM, Ned Deily <nad@acm.org> wrote:
This is not a good experience for users. Unless I'm missing something (and I hope I am), this issue really can't be hand-waved away. Make sure to understand that the way setuptools patches distutils makes it very sensible to any change made in distutils, even backward compatibles ones like in the 2.6 branch.
But I won't freeze distutils work because of that, and distutils is not to be blamed if setuptools is broken, neither Python.
I understand very well the issues that lead to the establishment of the Distribute project and I think it is great that you have taken on this - at times - pretty thankless effort. So thank you for doing so. I'm not trying to point fingers here; if I were, I'd start with me not recognizing this issue before 2.6.3 went out the door. I'm simply trying to put myself in the place of the "naive user", the target audience of easy_install. And users, naive or otherwise, don't know or care who is to blame, they'll just know that something about using Python 2.6.3 is broken.
So it's not a good experience for the users that's true, and we can try to enhance the Distribute documentation to help them as you suggested, and we are already helping because we've forked to try to provide some solutions.
But there's nothing else I can think of to help people. My advice would be that the projects that use setuptools just switch asap on distribute, which is actively maintained.
That's fine but they're not going to know about Distribute unless they stumble across discussions like this. And it's not their usage of setuptools that is the problem here. I think most of them would view this (rightly or wrongly) as: "Without warning, my package broke on a bug fix release of Python because of changes in Python." One solution *is* for the maintainers of affected packages to change their packaging and documentation to explicitly require Distribute. That's not going to happen overnight, of course. So is it possible to get a better idea of what the impact of this problem is going to be? I've already identified one real-world use case: (1) OS X users who install 2.6.3 from python.org and who need to install certain packages (lxml, appscript, zope-interfaces, others?). On what other platforms is this likely to be a problem? Windows *? Linuxes? If that can be identified, if necessary the distributors of Python installers can be informed so they can inform their users (note, that python.org is itself a distributor of Python installers). I don't have the expertise to make an assessment of that. Is it possible to get a better idea of what packages might be affected, i.e. what is it that these apps are using in their setup.py, or elsewhere, that causes the problem to appear? If so, it would be easier to warn the affected developers and users. Certainly some kind of warning could be added to the python.org 2.6.3 download pages and sent out of the various news lists. Perhaps a note about 2.6.3 and 3.x could be added to the original setuptools / easy_install PyPi page. I guess the bottom line question is: Is there anything more pro-active that should be done? -- Ned Deily, nad@acm.org
On Sat, 03 Oct 2009 14:17:50 -0700, Ned Deily <nad@acm.org> wrote:
On what other platforms is this likely to be a problem? Windows *? Linuxes? If that can be identified, if necessary the distributors of Python installers can be informed so they can inform their users (note, that python.org is itself a distributor of Python installers). I don't have the expertise to make an assessment of that.
From what I've seen, it affects all platforms.
Is it possible to get a better idea of what packages might be affected, i.e. what is it that these apps are using in their setup.py, or elsewhere, that causes the problem to appear?
I believe whenever the build_ext command is used, this problem would occur. One trivial package that fails is zope.interface. -srid
2009/10/3 Ned Deily <nad@acm.org>:
That's fine but they're not going to know about Distribute unless they stumble across discussions like this.
They are going to ask around, and somebody will know. Most reasonably, they are going to ask the maker of the module they are trying to install, and say "Hey your module doesn't work with Python 2.6.3. And that module guy will ask the python list. And the python list will know. People are not isolated. Information will reach them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi, for the folks using virtualenv-distribute, i forked it to make the last 0.6.3 install instead of 0.6.1. See : http://bitbucket.org/kiorky/virtualenv-distribute/ Install it: easy_install http://distfiles.minitage.org/public/externals/minitage/virtualenv-distribut... Ned Deily a écrit :
I'm afraid there is going to be a small deluge of very confused users who will end up needing to install Distribute but only when they eventually figure out why some packages with C extensions mysteriously no longer install after they upgrade to python 2.6.3. For example, following the package instructions to use setuptools easy_install, an easy_install lxml fails with 2.6.3 with the very cryptic:
File "build/bdist.macosx-10.3-fat/egg/setuptools/command/build_ext.py", line 85, in get_ext_filename KeyError: 'etree'
http://stackoverflow.com/questions/1512530/cant-install-lxml-python-2-6-3 -osx-10-6-snow-leopard
Appscript is another package that fails similarly. There must be others.
I don't know what's to be done about this awkward incompatibility now that 2.6.3 is out the door other than perhaps making sure maintainers of affected packages are aware of what their users are running into and can update their documentation.
There is one small thing that may help some users who find their way to http://pypi.python.org/pypi/distribute. OS X, for one, does not ship with wget however it does have curl. Suggest adding another example:
$ curl -O http://nightly.ziade.org/distribute_setup.py $ python distribute_setup.py
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
kiorky wrote:
Hi, for the folks using virtualenv-distribute, i forked it to make the last 0.6.3 install instead of 0.6.1.
See : http://bitbucket.org/kiorky/virtualenv-distribute/
Install it:
easy_install http://distfiles.minitage.org/public/externals/minitage/virtualenv-distribut...
So this is a fork of a fork? Nice :-( Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
2009/10/6 Chris Withers <chris@simplistix.co.uk>:
kiorky wrote:
Hi, for the folks using virtualenv-distribute, i forked it to make the last 0.6.3 install instead of 0.6.1.
See : http://bitbucket.org/kiorky/virtualenv-distribute/
Install it:
easy_install
http://distfiles.minitage.org/public/externals/minitage/virtualenv-distribut...
So this is a fork of a fork? Nice :-(
I think it's a fork of Virtualenv, no? Which uses a fork of distribute. :) We should get virtualenv to support Python3, and I suspect that means we need to get it to support Distribute on Python 2 as well, which probably is a good thing anyway. I do fear trying to understand how it works though, but maybe we can bribe/trick Ian into doing all the work it himself. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
2009/10/6 Lennart Regebro <regebro@gmail.com>:
I think it's a fork of Virtualenv, no? Which uses a fork of distribute. :)
I meant that it uses a fork of setuptools, obviously.... -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
It's just a fork of virtualenv to use distribute. It does not use a fork of distribute but distribute itself ;) Lennart Regebro a écrit :
2009/10/6 Lennart Regebro <regebro@gmail.com>:
I think it's a fork of Virtualenv, no? Which uses a fork of distribute. :)
I meant that it uses a fork of setuptools, obviously....
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
Anyway, it's released now on pypi as virtualenv-distribute-1.3.4.2. The code is also merged in florian branch and it has been decided that's the main repository. kiorky a écrit :
It's just a fork of virtualenv to use distribute. It does not use a fork of distribute but distribute itself ;)
Lennart Regebro a écrit :
2009/10/6 Lennart Regebro <regebro@gmail.com>:
I think it's a fork of Virtualenv, no? Which uses a fork of distribute. :) I meant that it uses a fork of setuptools, obviously....
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
2009/10/6 kiorky <kiorky@cryptelium.net>:
Anyway, it's released now on pypi as virtualenv-distribute-1.3.4.2.
The code is also merged in florian branch and it has been decided that's the main repository.
What is the florian branch, and in general, could you provide some more info. Your emails are very cryptic. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi Lennart, If i read 'virtualenv-distribute 1.3.4.2 on pypi' I can do some googling or even do some Pypi searching for 'virtualenv-distribute'. Thus, the first link found may be [1]. On this link, the second sentence is: """ The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/ """ [1] - http://pypi.python.org/pypi/virtualenv-distribute/ Lennart Regebro a écrit :
2009/10/6 kiorky <kiorky@cryptelium.net>:
Anyway, it's released now on pypi as virtualenv-distribute-1.3.4.2.
The code is also merged in florian branch and it has been decided that's the main repository.
What is the florian branch, and in general, could you provide some more info. Your emails are very cryptic. :)
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Tue, 06 Oct 2009 10:25:04 -0700, kiorky <kiorky@cryptelium.net> wrote:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/ """ [1] - http://pypi.python.org/pypi/virtualenv-distribute/
Just a suggestion: could someone make that /fschulze/virtualenv-distribute site (the current 'home page' of the project) link to the launchpad bug tracker? Up until now, I was not able to track down an issue tracker for this fork .. until you posted the PyPI link. This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days). -srid
On 07.10.2009, at 01:08, Sridhar Ratnakumar wrote:
On Tue, 06 Oct 2009 10:25:04 -0700, kiorky <kiorky@cryptelium.net> wrote:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/ """ [1] - http://pypi.python.org/pypi/virtualenv-distribute/
Just a suggestion: could someone make that /fschulze/virtualenv- distribute site (the current 'home page' of the project) link to the launchpad bug tracker? Up until now, I was not able to track down an issue tracker for this fork .. until you posted the PyPI link.
This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days).
The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :( Regards, Florian Schulze
On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote:
This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days).
The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :(
Uh...it's cleverly hidden under the "Issues" tab on the project page. S
On 07.10.2009, at 16:21, ssteinerX@gmail.com wrote:
On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote:
This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days).
The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :(
Uh...it's cleverly hidden under the "Issues" tab on the project page.
I had to enable it in the cleverly hidden "Admin" tab first. Regards, Florian Schulze
On Oct 7, 2009, at 10:51 AM, Florian Schulze wrote:
On 07.10.2009, at 16:21, ssteinerX@gmail.com wrote:
On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote:
This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days).
The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :(
Uh...it's cleverly hidden under the "Issues" tab on the project page.
I had to enable it in the cleverly hidden "Admin" tab first.
Told'ya it was cleverly hidden. ;-) I forgot about that; I think I had exactly the same "Where the heck's the issue tracker?" moment when I started my first repository. Why it's not enabled by default is one of the deep mysteries... Glad you found it! S
On 07.10.2009, at 01:08, Sridhar Ratnakumar wrote:
On Tue, 06 Oct 2009 10:25:04 -0700, kiorky <kiorky@cryptelium.net> wrote:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/ """ [1] - http://pypi.python.org/pypi/virtualenv-distribute/
Just a suggestion: could someone make that /fschulze/virtualenv- distribute site (the current 'home page' of the project) link to the launchpad bug tracker? Up until now, I was not able to track down an issue tracker for this fork .. until you posted the PyPI link.
This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days).
Ah, found the setting at bitbucket to enable the issue tracker, thanks kiorky to make me look deeper. http://bitbucket.org/fschulze/virtualenv-distribute/issues/?status=new&status=open Regards, Florian Schulze
kiorky wrote:
Hi Lennart,
If i read 'virtualenv-distribute 1.3.4.2 on pypi' I can do some googling or even do some Pypi searching for 'virtualenv-distribute'.
Thus, the first link found may be [1].
On this link, the second sentence is:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/
Add http://bitbucket.org/kiorky/virtualenv-distribute/ to the list and this, ladies and gentlemen, is why distributed source control sucks. Why are there effectively 3 forks on virtualenv now, just to get it to use distribute? Is it really so hard to work with Ian Bicking to be the real virtualenv using distribute instead of setuptools, especially in the way of the bdfl pronouncement? Chris
2009/10/9 Chris Withers <chris@simplistix.co.uk>:
Why are there effectively 3 forks on virtualenv now, just to get it to use distribute? Is it really so hard to work with Ian Bicking to be the real virtualenv using distribute instead of setuptools
Well I would expect Ian to want to take it a bit easy with the switch. But I think the time has come now. I sure would be happy to help after the PloneConf when I have some more time, also with getting it onto Python 3. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Fri, Oct 9, 2009 at 12:54 PM, Chris Withers <chris@simplistix.co.uk> wrote:
kiorky wrote:
Hi Lennart,
If i read 'virtualenv-distribute 1.3.4.2 on pypi' I can do some googling or even do some Pypi searching for 'virtualenv-distribute'.
Thus, the first link found may be [1].
On this link, the second sentence is:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/
Add http://bitbucket.org/kiorky/virtualenv-distribute/ to the list and this, ladies and gentlemen, is why distributed source control sucks.
Why are there effectively 3 forks on virtualenv now, just to get it to use distribute? Is it really so hard to work with Ian Bicking to be the real virtualenv using distribute instead of setuptools, especially in the way of the bdfl pronouncement?
I think the word "fork" here, in DVCS principles, just means that you copy a repository to work with, and eventually ask for the main repo to merge the changes. Which is fine imho. Tarek
2009/10/9 Tarek Ziadé <ziade.tarek@gmail.com>:
I think the word "fork" here, in DVCS principles, just means that you copy a repository to work with, and eventually ask for the main repo to merge the changes.
Yeah, it's just a branch, basically. But it is hard to get an overview. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Tarek Ziadé wrote:
I think the word "fork" here, in DVCS principles, just means that you copy a repository to work with, and eventually ask for the main repo to merge the changes.
So what's the main repo? What one of these three options should someone looking to use virtualenv-distribute take? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers a écrit :
Tarek Ziadé wrote:
I think the word "fork" here, in DVCS principles, just means that you copy a repository to work with, and eventually ask for the main repo to merge the changes.
So what's the main repo?
What one of these three options should someone looking to use Do i said something like *homepage* metadata? virtualenv-distribute take?
Chris
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
Hi Chris, As far as i know, we just give links for power users/developers to know how to find the actual related repositories. It s *CLEARLY* specified *IN THE HOMEPAGE METADATA* that the official thing lives inside florian branch. Those are not 3 forks, but 3 branches or the same code. And the florian branch is the reference as Linux kernel branch. And no DVCS is not a mess, this is just a mean to have bugfixes available as Fast as possible and it's a great way for the original authors to get and merge those fixes. AND no, virtualenv must continue to provide setuptools, backward compatibility, you know? Chris Withers a écrit :
kiorky wrote:
Hi Lennart,
If i read 'virtualenv-distribute 1.3.4.2 on pypi' I can do some googling or even do some Pypi searching for 'virtualenv-distribute'.
Thus, the first link found may be [1].
On this link, the second sentence is:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/
Add http://bitbucket.org/kiorky/virtualenv-distribute/ to the list and this, ladies and gentlemen, is why distributed source control sucks.
Why are there effectively 3 forks on virtualenv now, just to get it to use distribute? Is it really so hard to work with Ian Bicking to be the real virtualenv using distribute instead of setuptools, especially in the way of the bdfl pronouncement?
Chris
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Fri, Oct 9, 2009 at 2:03 PM, kiorky <kiorky@cryptelium.net> wrote:
AND no, virtualenv must continue to provide setuptools, backward compatibility, you know?
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it. Tarek
2009/10/9 Tarek Ziadé <ziade.tarek@gmail.com>:
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
I guess the point is that is should still work even if you don't want to switch to distribute? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Fri, Oct 9, 2009 at 2:36 PM, Lennart Regebro <regebro@gmail.com> wrote:
2009/10/9 Tarek Ziadé <ziade.tarek@gmail.com>:
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
I guess the point is that is should still work even if you don't want to switch to distribute?
If "you", is a package developer, yes of course = virtualenv will still behave as before
-- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
Lennart Regebro a écrit :
2009/10/9 Tarek Ziadé <ziade.tarek@gmail.com>:
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
I guess the point is that is should still work even if you don't want to switch to distribute?
Exact, i want that distribute usage must be explicit, moreover nowadays. -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
kiorky wrote:
Lennart Regebro a écrit :
2009/10/9 Tarek Ziadé <ziade.tarek@gmail.com>:
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it. I guess the point is that is should still work even if you don't want to switch to distribute?
Exact, i want that distribute usage must be explicit, moreover nowadays.
Huh? Why? I just don't buy this. We've effectively had a bdfl pronouncement that setuptools is dead. distribute 0.6 *is* now the "live supported setuptools" so any project that relies on the package called "setuptools" should now be using the "distribute" distribution... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 2009-10-09, Chris Withers <chris@simplistix.co.uk> wrote:
Huh? Why? I just don't buy this. We've effectively had a bdfl pronouncement that setuptools is dead. distribute 0.6 *is* now the "live supported setuptools" so any project that relies on the package called "setuptools" should now be using the "distribute" distribution...
Time for the BDFL to flip some ownership bits for setuptools in pypi. That would be the number one way out of this mess. I'm losing many otherwise-productive hours this way. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Reinout van Rees <reinout@vanrees.org> writes:
Time for the BDFL to flip some ownership bits for setuptools in pypi.
You appear to think the BDFL has powers outside the Python language and extending to third-party projects that are independent. Regardless of what I think of Setuptools or Distribute, I definitely am *very* glad the Python BDFL does not have the power to make a change to a third-party project as you're suggesting. -- \ “I was once walking through the forest alone and a tree fell | `\ right in front of me, and I didn't hear it.” —Steven Wright | _o__) | Ben Finney
On 2009-10-12, Ben Finney <ben+python@benfinney.id.au> wrote:
Reinout van Rees <reinout@vanrees.org> writes:
Time for the BDFL to flip some ownership bits for setuptools in pypi.
You appear to think the BDFL has powers outside the Python language and extending to third-party projects that are independent.
Regardless of what I think of Setuptools or Distribute, I definitely am *very* glad the Python BDFL does not have the power to make a change to a third-party project as you're suggesting.
I just read the rest of the thread on python dev. Yes, I should probably be glad it did not happen. OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now.
I'd just like to point out that if anyone finds setuptools to be "essential" to them, it's because they've chosen to make themselves dependent on it. It's always been known that it's a third-party package with no official support, and one that does some pretty screwy things to boot. It's always been on the cards that it would all fall down in a crashing heap one day. -- Greg
At 08:09 AM 10/12/2009 +0000, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install setuptools==dev or setuptools==dev06. ;-) It turned out to be easier than I expected to clean up pretty much all the outstanding (i.e. in the tracker) bugs this weekend, although that was mainly due to avoiding overhead by reading all the bugs together and making the changes more-or-less simultaneously. In this case, it was prompted mainly by the unfortunate, policy-breaking change to Python 2.6.3, but I'm thinking that maybe a quarterly Bug Weekend and subsequent maintenance release for setuptools might not be a bad thing.
On Tue, Oct 13, 2009 at 12:35 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 08:09 AM 10/12/2009 +0000, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install setuptools==dev or setuptools==dev06. ;-)
Nah it's ok, we've worked with Reinout and cleared out most of his problems today. (btw, no human can hold his breath for one year long ;) ) We are probably going to ship Distribute 0.6.5 next week after we will finish the review of your single gigantic commit on the setuptools package, so we can integrate more things if we can. Tarek.
On 2009-10-12, P.J. Eby <pje@telecommunity.com> wrote:
At 08:09 AM 10/12/2009 +0000, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install setuptools==dev or setuptools==dev06. ;-)
Relax, take a deep breath, go to #distutils in irc and be amazed at the speed by which Tarek is able to fix things. I'm helping Tarek debug stuff now so that I can switch to distribute :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Oct 13, 2009, at 3:15 AM, Reinout van Rees wrote:
On 2009-10-12, P.J. Eby <pje@telecommunity.com> wrote:
At 08:09 AM 10/12/2009 +0000, Reinout van Rees wrote:
OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist.... I'm pretty grumpy right now.
Relax, take a deep breath, and then easy_install setuptools==dev or setuptools==dev06. ;-)
Relax, take a deep breath, go to #distutils in irc and be amazed at the speed by which Tarek is able to fix things.
I'm helping Tarek debug stuff now so that I can switch to distribute :-)
Yes, now that people are allowed to help, things should improve rapidly. S
2009/10/12 Reinout van Rees <reinout@vanrees.org>:
Time for the BDFL to flip some ownership bits for setuptools in pypi. That would be the number one way out of this mess.
If there had been a reasonably possibility of the setuptools project actually being transferred to somebody, then this would have been done. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Huh? Why? I just don't buy this. We've effectively had a bdfl pronouncement that setuptools is dead. distribute 0.6 *is* now the "live supported setuptools" so any project that relies on the package called "setuptools" should now be using the "distribute" distribution...
Are you being wilfully ignorant here, Chris? he BDFL doesn't "control" setuptools, because it is a *third party package*. 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 iEYEARECAAYFAkrTqiQACgkQ+gerLs4ltQ5RqwCglAgztZ59zvpYYEz3KAZ08oYv bFUAn2wlowNTnuze6QQuJbXopCZ0bOdH =fgvv -----END PGP SIGNATURE-----
Tres Seaver wrote:
Huh? Why? I just don't buy this. We've effectively had a bdfl pronouncement that setuptools is dead. distribute 0.6 *is* now the "live supported setuptools" so any project that relies on the package called "setuptools" should now be using the "distribute" distribution...
Are you being wilfully ignorant here, Chris? he BDFL doesn't "control" setuptools, because it is a *third party package*.
Why is why an area as fundamentally important as this should be in the stdlib and not at the whim of third party developers ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi tarek, Tarek Ziadé a écrit :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
Living in my 0.6.x snail sandbox is not a solution. As it seems that Distribute 0.7 won't for a long time. "setuptools based" packages will be able to be installed via the distribute 0.6 branch but not compatible with "distribute based" stuff. Note that new things will eventually be packaged with the "new good way todo, aka with 0.7". There is a great risk that they can't live together aside. NOGO 0.7 packages wont be compatibles with setuptools installation/namespaces, so it will be impossible to install a lot of "setuptools based" packages aside with new stuff in with this way too. NOGO too. Maybe that the active community, zope, plone, django, etc. folks will take the step to repackage without a word, but there are more chances that more that one package on pypi that is not anymore maintened activly but, with 0.6, you can just use them without problems (eg: things with C code), will be unusable with 0.7. The transiton time will be long, there are no doubts. People has other things to do to repackage / rewrite their code even with a portage helper (ala 2to3)... It has a cost, it's useless, it's painfull, it's risky. Even more if you have undertested packages. But, in the meantime, you won't be able to do flawless deployments, you will have to masterise all about the full python deployment knowledge to install your stuff. That's unacceptable for me. The only way i saw is a compatibility layer inside 0.7 but what i have understood is that it's impossible by setuptools's implementation. Good or bad, that's not the point, i just want stability. I appreciate what you folks are doing with the distribute sphere, i have not that much problems with it, but i do not support that it breaks very badly the retro compatibilty for all things already packaged today, today tomorrow or in one year.
Tarek
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Fri, Oct 9, 2009 at 2:43 PM, kiorky <kiorky@cryptelium.net> wrote:
Hi tarek,
Tarek Ziadé a écrit :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
Living in my 0.6.x snail sandbox is not a solution. As it seems that Distribute 0.7 won't for a long time.
"setuptools based" packages will be able to be installed via the distribute 0.6 branch but not compatible with "distribute based" stuff. Note that new things will eventually be packaged with the "new good way todo, aka with 0.7". There is a great risk that they can't live together aside. NOGO
Why they can't ?
0.7 packages wont be compatibles with setuptools installation/namespaces, so it will be impossible to install a lot of "setuptools based" packages aside with new stuff in with this way too. NOGO too.
Why will it be impossible ? [...]
I appreciate what you folks are doing with the distribute sphere, i have not that much problems with it, but i do not support that it breaks very badly the retro compatibilty for all things already packaged today, today tomorrow or in one year.
Again, you will be able to use 0.6 and 0.7 together. or 0.6 alone, or 0.7 alone. Nothing will be broken in a distribution that uses 0.6. 0.6 stays maintained. Tarek
Tarek Ziadé a écrit :
On Fri, Oct 9, 2009 at 2:43 PM, kiorky <kiorky@cryptelium.net> wrote:
Hi tarek,
Tarek Ziadé a écrit :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it. Living in my 0.6.x snail sandbox is not a solution. As it seems that Distribute 0.7 won't for a long time.
"setuptools based" packages will be able to be installed via the distribute 0.6 branch but not compatible with "distribute based" stuff. Note that new things will eventually be packaged with the "new good way todo, aka with 0.7". There is a great risk that they can't live together aside. NOGO
Why they can't ?
As i understood all those readings, packages for 0.6 and 0.7 will be installable with the appropriate distribute version, thus side by side, but for me, they may be incompatibles together.
0.7 packages wont be compatibles with setuptools installation/namespaces, so it will be impossible to install a lot of "setuptools based" packages aside with new stuff in with this way too. NOGO too.
Why will it be impossible ?
pep-0382 is not equivalent to setuptools's one for example. Can i have been certified i will not have breakages when trying to import a setuptools based namespace package from a 0.7 sharing the same namespace?
[...]
I appreciate what you folks are doing with the distribute sphere, i have not that much problems with it, but i do not support that it breaks very badly the retro compatibilty for all things already packaged today, today tomorrow or in one year.
Again, you will be able to use 0.6 and 0.7 together. or 0.6 alone, or 0.7 alone.
Nothing will be broken in a distribution that uses 0.6.
0.6 stays maintained.
As i said ealier, there will be incompatibilities at some point. And also, to use them together, what a hell. For package A i need 0.6 (hard requirement), for package B i need 0.7 (hard requirement), for C i need 0.6. C depend on A which depends on B. I also have no sort of control over the maintenance of those products, think that the authors are dead. So, i ll have to manually install B for A to fulfill its requirements then C will install. Deployments will be simple :)
Tarek
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
kiorky kirjoitti:
Tarek Ziadé a écrit :
On Fri, Oct 9, 2009 at 2:43 PM, kiorky <kiorky@cryptelium.net> wrote:
Hi tarek,
Tarek Ziadé a écrit :
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
Living in my 0.6.x snail sandbox is not a solution. As it seems that Distribute 0.7 won't for a long time.
"setuptools based" packages will be able to be installed via the distribute 0.6 branch but not compatible with "distribute based" stuff. Note that new things will eventually be packaged with the "new good way todo, aka with 0.7". There is a great risk that they can't live together aside. NOGO
Why they can't ?
As i understood all those readings, packages for 0.6 and 0.7 will be installable with the appropriate distribute version, thus side by side, but for me, they may be incompatibles together.
0.7 packages wont be compatibles with setuptools installation/namespaces, so it will be impossible to install a lot of "setuptools based" packages aside with new stuff in with this way too. NOGO too.
Why will it be impossible ?
pep-0382 is not equivalent to setuptools's one for example. Can i have been certified i will not have breakages when trying to import a setuptools based namespace package from a 0.7 sharing the same namespace?
[...]
I appreciate what you folks are doing with the distribute sphere, i have not that much problems with it, but i do not support that it breaks very badly the retro compatibilty for all things already packaged today, today tomorrow or in one year.
Again, you will be able to use 0.6 and 0.7 together. or 0.6 alone, or 0.7 alone.
Nothing will be broken in a distribution that uses 0.6.
0.6 stays maintained.
As i said ealier, there will be incompatibilities at some point. And also, to use them together, what a hell. For package A i need 0.6 (hard requirement), for package B i need 0.7 (hard requirement), for C i need 0.6. C depend on A which depends on B. I also have no sort of control over the maintenance of those products, think that the authors are dead. So, i ll have to manually install B for A to fulfill its requirements then C will install. Deployments will be simple :)
I fail to follow this logic. If you install C, then both 0.6 and 0.7 will be installed as auto-dependencies (in case we decide to rename it to distribute2 or something), or just 0.7 (if we decide to provide a fat package).
Tarek
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Fri, Oct 9, 2009 at 3:32 PM, kiorky <kiorky@cryptelium.net> wrote:
Why they can't ?
As i understood all those readings, packages for 0.6 and 0.7 will be installable with the appropriate distribute version, thus side by side, but for me, they may be incompatibles together.
They "may" be ? what do you mean ? do you have a specific example ?
Why will it be impossible ?
pep-0382 is not equivalent to setuptools's one for example. Can i have been certified i will not have breakages when trying to import a setuptools based namespace package from a 0.7 sharing the same namespace?
I really doubt PEP 382 will break backward compatibility for that, you can't get rid of .pth file and the associated pgutil mechanism, from one python version to the other. If one day they are removed, this will happen at the minimum at 2.8 / 3.3, so in more than 2 years.
Nothing will be broken in a distribution that uses 0.6.
0.6 stays maintained.
As i said ealier, there will be incompatibilities at some point.
No.
And also, to use them together, what a hell. For package A i need 0.6 (hard requirement), for package B i need 0.7 (hard requirement), for C i need 0.6. C depend on A which depends on B. I also have no sort of control over the maintenance of those products, think that the authors are dead. So, i ll have to manually install B for A to fulfill its requirements then C will install. Deployments will be simple :)
It seems that you make the false assumption that a system can't have 0.6 and 0.7 at the same time. The "setuptools" package does not exists in 0.7 for example they are mutualy distinct. Tarek
Tarek Ziadé a écrit :
On Fri, Oct 9, 2009 at 3:32 PM, kiorky <kiorky@cryptelium.net> wrote:
And also, to use them together, what a hell. For package A i need 0.6 (hard requirement), for package B i need 0.7 (hard requirement), for C i need 0.6. C depend on A which depends on B. I also have no sort of control over the maintenance of those products, think that the authors are dead. So, i ll have to manually install B for A to fulfill its requirements then C will install. Deployments will be simple :)
It seems that you make the false assumption that a system can't have 0.6 and 0.7
No, this is not the case.
at the same time. The "setuptools" package does not exists in 0.7 for example they are mutualy distinct.
This may be quite current even if it's not a good habit to have circular dependencies between distributions. Imagine that. B(0.7) -> A(0.6). A(0.6) -> B(0.7). Can i have the same namespace "ns" shared between the twice distributions with both the setuptools namespaces implementation (A) and the pkg_util's one (B)? "Have" mean that i can import ns in both distributions. So, if: * I have old distributions with C code even not declaring they are relying on setuptools, installing with the 0.6 code automatically. * I have entry points and namespaces from 0.7 available to import in 0.6 and vice-versa. I will see no more objections. Another related thing, as i read the pep376 implementation, it may be good and easy to provide some wrappers to some setuptools very used objects like WorkingSet or Environment as similary code is already implemented to smoothly migrate existing code.
Tarek
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
kiorky a écrit : []
This may be quite current even if it's not a good habit to have circular dependencies between distributions. Imagine that.
B(0.7) -> A(0.6). A(0.6) -> B(0.7).
Can i have the same namespace "ns" shared between the twice distributions with both the setuptools namespaces implementation (A) and the pkg_util's one (B)? "Have" mean that i can import ns in both distributions.
So, if: * I have old distributions with C code even not declaring they are relying on setuptools, installing with the 0.6 code automatically. * I have entry points and namespaces from 0.7 available to import in 0.6 and vice-versa.
I will see no more objections.
Another related thing, as i read the pep376 implementation, it may be good and easy to provide some wrappers to some setuptools very used objects like WorkingSet or Environment as similary code is already implemented to smoothly migrate existing code.
Must i interprete no response as a global No ?
------------------------------------------------------------------------
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Wed, Oct 14, 2009 at 4:19 PM, kiorky <kiorky@cryptelium.net> wrote:
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular dependencies between distributions. Imagine that.
B(0.7) -> A(0.6). A(0.6) -> B(0.7).
Can i have the same namespace "ns" shared between the twice distributions with both the setuptools namespaces implementation (A) and the pkg_util's one (B)? "Have" mean that i can import ns in both distributions.
Not sur to follow this. Is that two different working sets ?
So, if: * I have old distributions with C code even not declaring they are relying on setuptools, installing with the 0.6 code automatically. * I have entry points and namespaces from 0.7 available to import in 0.6 and vice-versa.
I will see no more objections.
Another related thing, as i read the pep376 implementation, it may be good and easy to provide some wrappers to some setuptools very used objects like WorkingSet or Environment as similary code is already implemented to smoothly migrate existing code.
In Distribute 0.7.x we will provide new tools, and we won't try to provide backward compat. Projects that whish to use Distribute 0.7 features will have to switch to it I guess, so, depending on the project, it can use various strategy to migrate its code. Tarek
Tarek Ziadé a écrit :
On Wed, Oct 14, 2009 at 4:19 PM, kiorky <kiorky@cryptelium.net> wrote:
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular dependencies between distributions. Imagine that.
B(0.7) -> A(0.6). A(0.6) -> B(0.7).
Can i have the same namespace "ns" shared between the twice distributions with both the setuptools namespaces implementation (A) and the pkg_util's one (B)? "Have" mean that i can import ns in both distributions.
Not sur to follow this. Is that two different working sets ? Off course, no. Only two package i would have on sys.path as a time.
So, if: * I have old distributions with C code even not declaring they are relying on setuptools, installing with the 0.6 code automatically. * I have entry points and namespaces from 0.7 available to import in 0.6 and vice-versa.
I will see no more objections.
Another related thing, as i read the pep376 implementation, it may be good and easy to provide some wrappers to some setuptools very used objects like WorkingSet or Environment as similary code is already implemented to smoothly migrate existing code.
In Distribute 0.7.x we will provide new tools, and we won't try to provide backward compat.
Sad to hear as emulation is possible, at least with 0.6.
Projects that whish to use Distribute 0.7 features will have to switch to it I guess,
Hard switching will make people hesitate to switch or not and IMO more not. Providing backward compatibility which runs on populars case may give additional time to distribute newcomers to appreciate the new APIs and migrate their stuff.
so, depending on the project, it can use various strategy to migrate its code.
If the package maintainers can afford to think to those strategies. In the view of a new setuptools release (0.7), there will be three ways to have python packages installed, 2 or 3 ways (0.6, distribute, 0.7?) to have namespaces and/or entry points and incompatibilities at each level. Even if each package family live on its own without busing the others flavors, integration of all those packages will be a PITA. Add on this the burden to know each deployment thing.
Tarek
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On 2009-10-09, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Fri, Oct 9, 2009 at 2:03 PM, kiorky <kiorky@cryptelium.net> wrote:
AND no, virtualenv must continue to provide setuptools, backward compatibility, you know?
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
For something that's supposed to be a drop-in replacement, it sure makes it self noticeable. Note that I'm not holding that against distribute! The mess is of setuptools' making. - When using buildout, I get lots of warnings. The 1.4.2 isn't out yet, but I also won't update all old projects' pinned zc.buildout version so I'm stuck with warnings for a time. - On every computer where I installed it, somehow (I haven't figured out how, yet), the system python's distutils-replaced setuptools egg was borked. I had to revert the change and re-easy_install distribute (which worked afterwards). The stuff I see when this happens: Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c9-py2.5.egg usage: -c [options] requirement_or_url ... or: -c --help error: invalid command 'easy_install' Traceback (most recent call last): File "bootstrap.py", line 49, in <module> ) == 0 AssertionError - This weekend our buildbot (which I upgraded to use distribute) spit chunks all over me. Nothing builds anymore since I upgraded. Similar error as above. This morning I did the "replace egg and easy_install distribute" dance in the buildbot slave's python dir and now it barfs with: Creating directory '/srv/buildbot.thehealthagency.com/parts/slave1/doctree.schemas_slave1/build/bin'. Creating directory '/srv/buildbot.thehealthagency.com/parts/slave1/doctree.schemas_slave1/build/parts'. Creating directory '/srv/buildbot.thehealthagency.com/parts/slave1/doctree.schemas_slave1/build/develop-eggs'. While: Bootstraping. An internal error occured due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/tmp/tmpTuZdd7/zc.buildout-1.4.1-py2.5.egg/zc/buildout/buildout.py", line 1659, in main getattr(buildout, command)(args) File "/tmp/tmpTuZdd7/zc.buildout-1.4.1-py2.5.egg/zc/buildout/buildout.py", line 363, in bootstrap ws.require('zc.buildout') File "build/bdist.linux-i686/egg/pkg_resources.py", line 621, in require needed = self.resolve(parse_requirements(requirements)) File "build/bdist.linux-i686/egg/pkg_resources.py", line 519, in resolve raise DistributionNotFound(req) # XXX put more info here DistributionNotFound: setuptools I haven't been strangled yet by my colleagues for switching everything over. I'm convinced we have to do it. But I'd better fix it soon... Any idea what these kinds of errors mean? I can't believe I'm the only one. It happened on my osx laptop and on the linux server and within a buildout-installed buildbot. Why oh why hasn't setuptools' pypi entry be transfered to distribute.... Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
2009/10/12 Reinout van Rees <reinout@vanrees.org>:
- When using buildout, I get lots of warnings.
Me too, but those went a way when I re-ran the bootstrap... -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi. On Mon, Oct 12, 2009 at 9:10 AM, Reinout van Rees <reinout@vanrees.org> wrote:
- When using buildout, I get lots of warnings. The 1.4.2 isn't out yet, but I also won't update all old projects' pinned zc.buildout version so I'm stuck with warnings for a time.
Note that buildout is only really supported with the distribute 0.6.4 release and needs the latest bootstrap from http://nightly.ziade.org/bootstrap.py. We fixed a variety of issues with buildout over the weekend. It seems to work with zc.buildout 1.4.1 now, though. Hanno
On 2009-10-12, Hanno Schlichting <hanno@hannosch.eu> wrote:
Hi.
On Mon, Oct 12, 2009 at 9:10 AM, Reinout van Rees <reinout@vanrees.org> wrote:
- When using buildout, I get lots of warnings. The 1.4.2 isn't out yet, but I also won't update all old projects' pinned zc.buildout version so I'm stuck with warnings for a time.
Note that buildout is only really supported with the distribute 0.6.4 release and needs the latest bootstrap from http://nightly.ziade.org/bootstrap.py. We fixed a variety of issues with buildout over the weekend. It seems to work with zc.buildout 1.4.1 now, though.
The problems were with the stuff from last weekend. Well, after some additional small fixes yesterday, most of the problems are indeed gone. What needs doing iirc: - Installing distribute with buildout shouldn't result in distribute doing anything with the system python's setuptools (as there are problems that way). The latest bootstrap already allows setuptools and distribute to co-exist happily in a shared eggs dir! - Checking what happens in the corner case when buildOUT sets up a buildBOT which sets up a virtualenv for a build slave which runs a buildOUT :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Mon, Oct 12, 2009 at 9:10 AM, Reinout van Rees <reinout@vanrees.org> wrote:
On 2009-10-09, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Fri, Oct 9, 2009 at 2:03 PM, kiorky <kiorky@cryptelium.net> wrote:
AND no, virtualenv must continue to provide setuptools, backward compatibility, you know?
The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice it.
For something that's supposed to be a drop-in replacement, it sure makes it self noticeable. Note that I'm not holding that against distribute! The mess is of setuptools' making.
- When using buildout, I get lots of warnings. The 1.4.2 isn't out yet, but I also won't update all old projects' pinned zc.buildout version so I'm stuck with warnings for a time.
Please try with your current zc.buildout, we've also fixed compatiblity with older zc.buildout versions yesterday so it should work.
Any idea what these kinds of errors mean? I can't believe I'm the only one. It happened on my osx laptop and on the linux server and within a buildout-installed buildbot.
Do you happen to have a shared eggs directory ? if it's the case, all buildouts that uses it need to be re-bootstrapped with the distribute boostrap Tarek
Chris Withers <chris@simplistix.co.uk> writes:
Why are there effectively 3 forks on virtualenv now, just to get it to use distribute? Is it really so hard to work with Ian Bicking to be the real virtualenv using distribute instead of setuptools, especially in the way of the bdfl pronouncement?
You do realise that, because those branches share ancestry with Ian's branch, they can be merged back in? That, by being able to put a branch online that the VCS tool knows how to merge, it's much *easier* to collaborate than with centralised VCS? That, without any explicit co-ordination between the parties, Ian Bicking can take any of those branches and merge whatever changes he finds appropriate back into his own branch, and vice versa? This is the strength of distributed VCS like Bazaar, Git, and Mercurial: you're seeing *more* collaboration because there is less administrative barrier required to put a branch online and still have it be VCS-compatible with the original. -- \ “It is seldom that liberty of any kind is lost all at once.” | `\ —David Hume | _o__) | Ben Finney
On Fri, Oct 9, 2009 at 5:54 AM, Chris Withers <chris@simplistix.co.uk> wrote:
kiorky wrote:
Hi Lennart,
If i read 'virtualenv-distribute 1.3.4.2 on pypi' I can do some googling or even do some Pypi searching for 'virtualenv-distribute'.
Thus, the first link found may be [1].
On this link, the second sentence is:
""" The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/
Add http://bitbucket.org/kiorky/virtualenv-distribute/ to the list and this, ladies and gentlemen, is why distributed source control sucks.
I think one (pjenvey) was an experiment, and another is actually a released virtualenv-distribute package (updating the name in setup.py, etc). And the third, I dunno. Anyway -- I'm reluctant to switch virtualenv to distribute right now, as I'm not confident it is ready for people to use distribute without even realizing it. Because if someone just upgrades virtualenv and starts using it, they'll get whatever virtualenv is distributed with. I'd be happy to include a --distribute option if someone wants to repackage one of these forks to include both setuptools and distribute support. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
Ian Bicking a écrit :
On Fri, Oct 9, 2009 at 5:54 AM, Chris Withers <chris@simplistix.co.uk> wrote:
kiorky wrote:
I think one (pjenvey) was an experiment, and another is actually a released virtualenv-distribute package (updating the name in setup.py, etc). And the third, I dunno.
The third (mine) was a bump to distribute-current and a merge from current virtualenv basecode.
Anyway -- I'm reluctant to switch virtualenv to distribute right now, as I'm not confident it is ready for people to use distribute without even realizing it. Because if someone just upgrades virtualenv and starts using it, they'll get whatever virtualenv is distributed with. I'd be happy to include a --distribute option if someone wants to repackage one of these forks to include both setuptools and distribute support.
I may not have sufficient time right now, but this feature maybe be quite easy to do. -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
Ian Bicking wrote:
I think one (pjenvey) was an experiment, and another is actually a released virtualenv-distribute package (updating the name in setup.py, etc). And the third, I dunno.
Anyway -- I'm reluctant to switch virtualenv to distribute right now, as I'm not confident it is ready for people to use distribute without even realizing it.
How so? distribute 0.6 = setuptools 0.6 + bugfixes. How would sticking with a bug-riddled piece of code be better than moving to the same code with a few of the bugs fixed? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
participants (21)
-
Alex Grönholm -
Barry Warsaw -
Ben Finney -
Bill Janssen -
Chris Withers -
David Cournapeau -
Florian Schulze -
Greg Ewing -
Hanno Schlichting -
Ian Bicking -
Jeff Rush -
kiorky -
Lennart Regebro -
Ned Deily -
P.J. Eby -
Reinout van Rees -
Sridhar Ratnakumar -
ssteinerX＠gmail.com -
Tarek Ziadé -
Tres Seaver -
Zooko Wilcox-O'Hearn