Re: [Distutils] Proposal for Distribute 0.7
At 02:32 PM 10/15/2009 +0200, Tarek Ziadé wrote:
That would make us happy, because we would be able to work and continue if you are not available sometimes without the feeling that we are locked, and that would give you the manpower you miss to develop some of your idea.
So... you've explained what part of this proposal will make you happy. Where's the part that will make me happy? Generally speaking, that's how a "win-win" proposal works. There's a second issue, too. You've repeatedly smeared setuptools on Python-Dev to cover your mistakes, and you have *yet* to retract or amend any of those statements or apologize for them in any of the places where you made them -- despite numerous requests that you do so. In each case where I've made a request, I know you've received the request, because you've replied to the email or comment in which I made it. But in none of your replies have you even *acknowledged* the issue, let alone done anything about it. Instead, you've either changed the venue, the subject, or just launched a new smear. This latest "proposal" of yours is of course just another such subject and venue change, in reply to one of my more recent requests (via Reddit comment) that you do something about this outstanding issue. But if you were genuinely serious about the things you claim to be interested in, you might have paid attention to such things as my mentions that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). In my book, the mere fact that you haven't asked me who those team members are, or offered to step down in favor of them (either privately OR publicly), tells me everything I need to know about where your real interest in this matter lies. Now, don't get me wrong - I'm not blacklisting you or refusing to support you. You are no less a user of setuptools than any other, after all. To the extent that you are courteous in your requests regarding setuptools, you will get reasonably courteous responses from me, as has been the case on Python-Dev and here in the last few days. (And for that matter, all along!) But please don't bother floating any more proposals for some sort of direct collaboration or co-operation between you and I, not now, or ever again, until such time as you have shown as consistent a track record of behaving with integrity, as you've shown a *lack of* in your interactions with me. Because as of right now, I can't trust you enough to work with you. I can't trust you not to blame every mistake you make on me, and then say, "oh let's just forget about everything" when you're called on it. I can't trust you to admit when you don't know something (see our recent Catalog-SIG exchange), or to not throw my agreement to work with you back in my face the first time we disagree on something. And these things alone would be more than enough reason not to work on a software project with someone. But at this point, I can't even trust you to not immediately follow up my mere *agreement* to work with you, with a blog post like "PJE finally comes to his senses" or some such rubbish. Your political gaming behavior is a deal-breaker for me, and it's not something that any behavior you do *now* can fix. I've tried for months to give you the benefit of the doubt, the benefit of the language barrier, and maybe even the benefit of a complete lack of sensitivity or clue on your part. And, most recently, you've had no fewer than *five* extra chances from me to act with integrity, but you've chosen to showboat instead. Every. Single. Time. So, good luck with that, 'cause I'm done with it. To the rest of the Distribute team: I have absolutely no quarrel with any of you, as far as I know, and I remain open to an (off-list) discussion on any topics or win-win proposals you'd like to discuss. P.S. Tarek: if your next move is to issue a series of halfhearted, backhanded retractions so you can whine that you did what I asked and I still won't work with you, please don't bother. It's not really credible evidence of your integrity at this point, so I'm done with asking you for anything. IOW, this is *not* a sixth request for a retraction, it's the termination of my many, many attempts to deal with you in good faith. P.P.S. Everyone else: please don't clog the SIG mailing list with further discussion on this topic. If you feel the need to flame me for some reason, please show more consideration to the group than Tarek has, by sending it to me in private, or go rant on your blog or twitter if your need for attention is too great. In return, I will guarantee this to be my last mailing list post on this subject. (I guarantee that I'm at *least* as tired of it as you are.) Thanks in advance.
On Thu, Oct 15, 2009 at 7:50 PM, P.J. Eby <pje@telecommunity.com> wrote:
So, good luck with that, 'cause I'm done with it.
I am sorry we were unable to understand each other. I proposed you to join because I felt it was the right thing to do. But that doesn't matter at this point. We'll just work on our side. Good luck for your projects too then.
that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). ...asked me who those team members are
I'm asking. Who are they and, if you are willing to give them access, have you offered it and they've declined, or you were waiting until...what? You had Tarek's acknowledgement or permission? We, regular Python users, have been asking for you to let someone help with setuptools for years since you obviously have other priorities and the various issues in setuptools have affected many of us in various ways. Are you really willing to let anyone help? Really? Do it, then, and let's just let this asinine infighting go down in history as one of the stupidest things a language community has ever done to its own credibility in public and move on. Not having an evolving, comprehensive packaging system, that is keeping up with the ever-changing requirements of our daily work is really hurting the language, the community, and us, as working Python programmers, every day. Thanks, S
At 02:38 PM 10/15/2009 -0400, ssteinerX@gmail.com wrote:
that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). ...asked me who those team members are
I'm asking. Who are they and, if you are willing to give them access, have you offered it and they've declined, or you were waiting until...what? You had Tarek's acknowledgement or permission?
I am not trying to poach anyone or stir up trouble, which is why I've taken a very passive public stance on the issue -- although it has included me naming names in certain venues, including here. However, I *am* in private contact with more than one member of the Distribute team, each of whom first contacted me. In order to avoid creating any further drama here or in the Distribute team, I will leave it up to them to make any public statements, when/if they choose to confer with their colleagues on the matter. (I would prefer, of course, a joint statement at the appropriate time.) I wish that such complications weren't necessary. If cooler heads had prevailed in July, this could have and likely would have been resolved back then.
We, regular Python users, have been asking for you to let someone help with setuptools for years since you obviously have other priorities and the various issues in setuptools have affected many of us in various ways.
The only reason I've done an 0.6c10 is because of a policy-breaking change to Python that breaks setuptools users, and that can't be worked around with configuration, command-line options, or other tweaking of the runtime environment -- as was able to be done with approximately 9 out of 10 of the setuptools bugs in the tracker. If it weren't for that, I'd have been more-or-less happy to let Distribute become the quasi-official replacement for setuptools 0.6, despite my annoyance at some of the public comments made by its promoter(s) prior to the 2.6.3 issue. Indeed, as previously stated, I even tried to arrange a handoff of 0.6, wherein the changes made in Distribute would've been released as 0.6c10 or 0.6final back in July... and public talks broke down due to certain persons' flaming and posturing. That's one reason I'm only doing off-list talks now -- less chance of random jerks inserting themselves into the middle of the discussion, making me think they're part of Distribute and that their comments reflect Distribute policy (as also happened back in July). Also, no need for persons on either side to put up any posture or spin, when there's no audience to play to.
Are you really willing to let anyone help? Really?
Indeed. There's a list, and some of them obviously have time to work on Distribute, so it's not a matter of me only picking people who don't have any time, as Tarek and others have more than once accused me of.
Do it, then,
Discussions are ongoing. Also, I've made it pretty plain for a long time that if Ian Bicking or Jim Fulton were ever willing to take it over, I'd hand it *all* over -- 0.7 as well as 0.6 -- and happily retire from the distribution tools business. I trust their vision as architects, and their track record of supporting their users IMO speaks for itself. Both are past contributors of non-trivial features to setuptools, as well as accomplished installation tool developers in their own right. It would be a joy and an honor to turn the keys over to either one of them, either as an individual or as the leader of a new team. (I would love to see some of pip and buildout's features integrated in setuptools 0.7, for example.) (Ian, btw, already has PyPI maintainer rights to setuptools, and Jim already has commit rights to setuptools SVN... giving further lie to the idea that I'm not willing to give people access or let them help.) That having been said, there are definitely other people I'd give varying degrees of access to, just not at the "here, take it, please, I want you to have it!" level I would grant to Ian or Jim. ;-)
On Oct 15, 2009, at 3:55 PM, P.J. Eby wrote: [a whole bunch of stuff...] Understood and I've observed the public portions of all of this. Much of it has not been pretty. Personality conflicts aside, I wonder if it would be possible to move some portion of the base of both setuptools and Distribute to some sort of shared foundation. That would reduce the amount of duplicate work that I can see coming out of this divergence and, perhaps, provide a basis on top of which setuptools and Distribute can continue to evolve. This kind of "shared utility" project could, perhaps, be undertaken by someone that the two team leaders both know and trust and could become a shared resource instead of having the two teams competing for the extremely valuable (and severely limited) pool of people you would trust to work on this. The thing that has bothered me for years is that, while the code that's being installed is generally of higher quality in the Python world, the tools for doing so in the Ruby world have pulled ahead and now do a better job of installing code that's not as good. Unfortunately, that can give the Ruby solution a visible head start that often times can't be overcome in the minds of management, regardless of the relative quality of the resultant products. Thanks, S
On Thu, Oct 15, 2009 at 1:12 PM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Oct 15, 2009, at 3:55 PM, P.J. Eby wrote:
[a whole bunch of stuff...]
Understood and I've observed the public portions of all of this. Much of it has not been pretty.
Personality conflicts aside, I wonder if it would be possible to move some portion of the base of both setuptools and Distribute to some sort of shared foundation.
distutils in stdlib seems like this foundation. I'm not sure it would be beneficial to inject another layer (and therefore dependency) between distutils and setuptools/distribute, but will defer that judgment to the maintainers involved in the 3 projects (distutils, setuptools, and distribute). I think everyone would prefer only setuptools or distribute to survive in the long term as the current situation is less than ideal from a technical and social standpoint. When one of these projects ultimately deprecates the other, any shared foundation they created would be reduced to needless complexity and cruft. But I'm just a user/observer like yourself, so someone with a bit more authority might want to chime in. :-) HTH, Michael Schurter
On Thu, Oct 15, 2009 at 10:23 PM, Michael Schurter <michael@susens-schurter.com> wrote:
On Thu, Oct 15, 2009 at 1:12 PM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Oct 15, 2009, at 3:55 PM, P.J. Eby wrote:
[a whole bunch of stuff...]
Understood and I've observed the public portions of all of this. Much of it has not been pretty.
Personality conflicts aside, I wonder if it would be possible to move some portion of the base of both setuptools and Distribute to some sort of shared foundation.
distutils in stdlib seems like this foundation. I'm not sure it would be beneficial to inject another layer (and therefore dependency) between distutils and setuptools/distribute, but will defer that judgment to the maintainers involved in the 3 projects (distutils, setuptools, and distribute).
I'll talk as the Distutils maintainer. I have been working for quite some in cleaning up Distutils code, and its test coverage to make it ready to evolve in 2.7/2.8, 3.2/3.3. This time is coming soon. The plan is to include bits by bits setuptools goodies into Distutils. But only through all the legit PEPs work we are doing (PEP 386/376/390) with Distribute *or* Setuptools being the incubator of those. But as ssteinerX said, this can ony happen if the incubator of Distutils is managed like an open-source community project, and that is currenly impossible in the way Setuptools is managed. Just because this kind of project needs more that one involved person. That's what we are trying to do in Distribute, where there are already quite a few python core commiters and buildout experts, and that's why I have proposed to join forces there. We worked lately on a daily basis and talk at #distutils on freenode about it. Sorry, no one is called "Ian" or "Jim" yet in there. Just 7 or so people that have been working for years with packaging and setuptools. That's pretty much the team which is required for such a project. Now, ssteinerX, what do you mean exactly by shared foundation ? Cheers Tarek
Warning: 3 part message. It's all related so I decided to bundle it rather than starting several new threads on the already over-burdened distutils list. On Oct 15, 2009, at 5:06 PM, Tarek Ziadé wrote:
Now, ssteinerX, what do you mean exactly by shared foundation ?
Well, at the moment, setuptools 6.10rc and Distribute 0.6.6 share only one identical directory; tests. (tests in the root directory which only contains shlib_test which I'm not even sure is used by anyone) Many other files are only different by a few lines, some additions to Distribute are just for Python 3 compatibility. Some of the changes are only in the way message text is distributed over a couple of lines (the kind of clean-up people naturally do as they're assimilating a product they didn't write), some extra comments, sometimes the wording (Couldn't vs. Could not) of an error message. Some of the files (e.g. setuptools/archive_util.py) are only different by a bit of whitespace. In taking a closer look, the two products are still very close to each other but it would take a careful person a solid few days or a week to merge them back together into a single code-base, if that would even be desirable. I had thought going forward would be to take some of the utility type functionality that is unlikely to change (archive_util.py for example) and move them to a shared utility library. This is probably unrealistic given the dynamics of the current situation, but it was a nice idea ;-). Thanks, S P.S. While I was in there, I did a little actual work. Not much, but now I feel like I've made a contribution, however small... ;-). Does this make me a "contributor?" This is from the archive pulled down by: # wget http://pypi.python.org/packages/source/d/distribute/distribute-0.6.6.tar.gz While I was pawing around, I noticed that, in distribute-0.6.6/ setuptools/command/alias.py, line 12, the <> operator is used. Since that's not allowed in Python 3.x, the test suite must not cover this 'cause Python 3 would barf. So...I whipped out my command line and: find . -name "*.py" -exec grep "<>" {} \; -print I get: (~/src/distribute-0.6.6/setuptools)# find . -name "*.py" -exec grep "<>" {} \; -print if arg.split()<>[arg]: if self.remove and len(self.args)<>1: ./command/alias.py if safe is None or bool(safe)<>flag: ./command/bdist_egg.py if self.verbose<>self.distribution.verbose: if k<>'target_version': if len(parts)<>2 or not name.endswith('.pth'): ./command/easy_install.py str(version)<>"unknown" and version >= self.requested_version ./depends.py if p<>package and not p.startswith(pfx) if p<>package and not p.startswith(pfx) if p.name<>package and not p.name.startswith(pfx) ./dist.py if cs.hexdigest()<>info[4:]: ./package_index.py Those aren't going to fly in Python 3 and can be safely removed for 2.x as well. A patch would be silly, just go fix it ;-). Thanks, S P.S.S. Part of the problem we'd have with merging the two products to form a single codebase is that there are some differences between the ways the tickets have been closed in the two products. Distribute's fixes are committed against the bugs in its tracker so it's pretty easy to see what change fixed what. Not so much in setuptools where many things are in one big mega-commit.
The latest commit you've made in setuptools package is still cryptic to us because it fixes many things at once.
Sorry about that, but it was pretty much the only way to get it done in a weekend, without the overheads of separate commit messages, doc changes, and backporting killing me. Those overheads were the main reason I wasn't making changes more often; I dreaded the amount of work involved.
Also, as it happened, I was able to fix multiple problems with single changes this way.
I don't mean to take another pot-shot a PJE, but the facts is the facts and this shows clearly why the product with the open development process should be the one supported by the community.
Also, I've made it pretty plain for a long time that if Ian Bicking or Jim Fulton were ever willing to take it over, I'd hand it *all* over -- 0.7 as well as 0.6 -- and happily retire from the distribution tools business.
I'd love to see this be the last release of setuptools so if you're the aforementioned "Ian" or "Jim", could you please, please, very temporarily, accept the burden of "setuptools maintainer" so it can die an elegant, compatible, controlled, peaceful death, being merged into and supplanted by Distribute after long and good service to the Python world? We really need a good, modern, open, constantly evolving packaging system to keep Python competitive. Thanks, S
On Fri, Oct 16, 2009 at 3:39 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
Some of the files (e.g. setuptools/archive_util.py) are only different by a bit of whitespace.
archive_util, in the mid term (2.7/3.2) will dissapear, in favor of changes in Distutils side.
In taking a closer look, the two products are still very close to each other but it would take a careful person a solid few days or a week to merge them back together into a single code-base, if that would even be desirable.
We had a "setuptools-compatible" branch for a while when PJE said he might use our work to release setuptools, but that didn't happened and we moved on. [please no flame here,it's just a fact : it didn't happen. period] At this point, the code base is backward compatible, but is slightly changing yes (we are working in bug fixes so..)
P.S.
While I was in there, I did a little actual work. Not much, but now I feel like I've made a contribution, however small... ;-). Does this make me a "contributor?"
Yes absolutely. Then if you keep them coming and you will be able the have a contributor access. btw, anyone that has a history in managing a known project for years in the community can get a commit access instantly because we want this project to be open and to be run by the people that are the ones doing packages every day. They know what they are doing. As, for the quality of the code, the current quality is very low in many ways, so, for obvious bug patches, we trust anyone that is already running a project succesfully, and we are counting on the fact that many eyes are now watching the changesets being done. Remember that 0.6.x is bugfix only. The only hard part in setuptools is understanding what the code is doing because it's hard to read, overdesigned and overcomplex and with giant monolithic modules.
This is from the archive pulled down by:
# wget http://pypi.python.org/packages/source/d/distribute/distribute-0.6.6.tar.gz
While I was pawing around, I noticed that, in distribute-0.6.6/setuptools/command/alias.py, line 12, the <> operator is used.
Since that's not allowed in Python 3.x, the test suite must not cover this 'cause Python 3 would barf.
So...I whipped out my command line and:
find . -name "*.py" -exec grep "<>" {} \; -print
I get:
(~/src/distribute-0.6.6/setuptools)# find . -name "*.py" -exec grep "<>" {} \; -print if arg.split()<>[arg]: if self.remove and len(self.args)<>1: ./command/alias.py if safe is None or bool(safe)<>flag: ./command/bdist_egg.py if self.verbose<>self.distribution.verbose: if k<>'target_version': if len(parts)<>2 or not name.endswith('.pth'): ./command/easy_install.py str(version)<>"unknown" and version >= self.requested_version ./depends.py if p<>package and not p.startswith(pfx) if p<>package and not p.startswith(pfx) if p.name<>package and not p.name.startswith(pfx) ./dist.py if cs.hexdigest()<>info[4:]: ./package_index.py
Those aren't going to fly in Python 3 and can be safely removed for 2.x as well. A patch would be silly, just go fix it ;-).
Thanks ! we will fix it. The code base is not well covered in the tests, so this problem was not tackled. Notice that the latest released, if run under Python 3, will convert in the fly the code, using 2to3, so make sure the tests are run after 2to3 (that's what is supposed to happen) If you find anything else, please come in #distutils (freenode) Cheers Tarek
On Oct 16, 2009, at 4:24 AM, Tarek Ziadé wrote:
On Fri, Oct 16, 2009 at 3:39 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
Some of the files (e.g. setuptools/archive_util.py) are only different by a bit of whitespace.
archive_util, in the mid term (2.7/3.2) will dissapear, in favor of changes in Distutils side.
Ok, it was just a datapoint, not a suggestion that it be retained.
In taking a closer look, the two products are still very close to each other but it would take a careful person a solid few days or a week to merge them back together into a single code-base, if that would even be desirable.
We had a "setuptools-compatible" branch for a while when PJE said he might use our work to release setuptools, but that didn't happened and we moved on. [please no flame here,it's just a fact : it didn't happen. period]
At this point, the code base is backward compatible, but is slightly changing yes (we are working in bug fixes so..)
Ok, after reviewing the code, I can see that maintaining "common code" would not actually be a good idea because it's not worth retaining.
While I was in there, I did a little actual work. Not much, but now I feel like I've made a contribution, however small... ;-). Does this make me a "contributor?"
Yes absolutely. Then if you keep them coming and you will be able the have a contributor access.
Thanks. At the moment, I, frankly, wouldn't touch that code with a 10 foot pole. I had never actually sat down to do anything resembling a "code review" on the setuptools code and, after doing so, I really think it should just be scrapped as quickly as possible. Dragging any of it along, for whatever reason, is just going to slow progress. The test coverage is pretty much non-existent and, without that, trying to figure out the intent of this code is pointlessly difficult. It'd just be easier to write the tests, write the code, and move on.
As, for the quality of the code, the current quality is very low in many ways, so, for obvious bug patches, we trust anyone that is already running a project succesfully, and we are counting on the fact that many eyes are now watching the changesets being done.
Remember that 0.6.x is bugfix only.
Understood.
The only hard part in setuptools is understanding what the code is doing because it's hard to read, overdesigned and overcomplex and with giant monolithic modules.
I don't know that I'd call what I saw "designed." Complex, yes, but design implies a plan and known direction, communicated by design documents with tests that prove the code is working as expected. This is not designed by any objective standard I'd use. Maybe PJE is some sort of savant who can keep the myriad details of a piece of code like this in his head but "design" is not that.
This is from the archive pulled down by:
# wget http://pypi.python.org/packages/source/d/distribute/distribute-0.6.6.tar.gz
While I was pawing around, I noticed that, in distribute-0.6.6/setuptools/command/alias.py, line 12, the <> operator is used.
Those aren't going to fly in Python 3 and can be safely removed for 2.x as well. A patch would be silly, just go fix it ;-).
Thanks ! we will fix it. The code base is not well covered in the tests, so this problem was not tackled. Notice that the latest released, if run under Python 3, will convert in the fly the code, using 2to3, so make sure the tests are run after 2to3 (that's what is supposed to happen)
Yes, I'm sure 2to3 can fix it, but the less work it has to do, the fewer chances for mistakes in the automatic conversion. Not that I'd expect this to break something but having the 2to3 log less cluttered with simple things like this that can be easily done by hand cuts down on the amount of stuff that has to be reviewed in case of a problem.
If you find anything else, please come in #distutils (freenode)
Will do... S
At 10:46 AM 10/16/2009 -0400, ssteinerX@gmail.com wrote:
I don't know that I'd call what I saw "designed." Complex, yes, but design implies a plan and known direction, communicated by design documents with tests that prove the code is working as expected.
This is not designed by any objective standard I'd use.
You are correct; setuptools itself was not particularly designed. Eggs are, entry points are, a few other odds and ends were designed, but setuptools itself (and *especially* easy_install) are a collection of hacks upon hacks, mostly done in a rush to get something out the door... which as soon as it became popular, locked into a cycle of not having enough time to do improvements, because maintenance was taking so much time.
Maybe PJE is some sort of savant who can keep the myriad details of a piece of code like this in his head
Nope. Why do you think I've not been thrilled about working on it? ;-)
On Oct 16, 2009, at 11:41 AM, P.J. Eby wrote:
At 10:46 AM 10/16/2009 -0400, ssteinerX@gmail.com wrote:
I don't know that I'd call what I saw "designed." Complex, yes, but design implies a plan and known direction, communicated by design documents with tests that prove the code is working as expected.
This is not designed by any objective standard I'd use.
You are correct; setuptools itself was not particularly designed. Eggs are, entry points are, a few other odds and ends were designed, but setuptools itself (and *especially* easy_install) are a collection of hacks upon hacks, mostly done in a rush to get something out the door... which as soon as it became popular, locked into a cycle of not having enough time to do improvements, because maintenance was taking so much time.
Yup. Understood. It's a vicious circle/cycle that I'm sure we've all been trapped in at one time or another; just not quite so publicly or with such a large impact on so many people. And to do it for free, besides! Betcha' you'll think thrice next time...and say nah, no thanks...
Maybe PJE is some sort of savant who can keep the myriad details of a piece of code like this in his head
Nope. Why do you think I've not been thrilled about working on it? ;-)
Welp...here's to hoping you're freed from that burden partially of your own making if not choosing... S
On 2009-10-16, P.J. Eby <pje@telecommunity.com> wrote:
At 10:46 AM 10/16/2009 -0400, ssteinerX@gmail.com wrote:
This is not designed by any objective standard I'd use.
You are correct; setuptools itself was not particularly designed. Eggs are, entry points are, a few other odds and ends were designed, but setuptools itself (and *especially* easy_install) are a collection of hacks upon hacks, mostly done in a rush to get something out the door... which as soon as it became popular, locked into a cycle of not having enough time to do improvements, because maintenance was taking so much time.
Ah, the perils of success :-) And you've had a lot of success with it. I still remember the more-or-less painful days of having to extract and install everything by hand. And I remember being yealous at perl's "oh, just install x y and z" dependency handling experience. Hurray for having eggs, pypi and friends! 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 16, 2009, at 8:10 PM, Reinout van Rees wrote:
On 2009-10-16, P.J. Eby <pje@telecommunity.com> wrote:
At 10:46 AM 10/16/2009 -0400, ssteinerX@gmail.com wrote:
This is not designed by any objective standard I'd use.
You are correct; setuptools itself was not particularly designed. Eggs are, entry points are, a few other odds and ends were designed, but setuptools itself (and *especially* easy_install) are a collection of hacks upon hacks, mostly done in a rush to get something out the door... which as soon as it became popular, locked into a cycle of not having enough time to do improvements, because maintenance was taking so much time.
Ah, the perils of success :-) And you've had a lot of success with it. I still remember the more-or-less painful days of having to extract and install everything by hand.
And I remember being yealous at perl's "oh, just install x y and z" dependency handling experience.
Hurray for having eggs, pypi and friends!
Here's to catching up with Perl and Ruby and maybe even passing them, finally. S
I really love this stuff.. It's better than soap opera.. We have jerks, interjectors, behind the scenes plots, secret messages, moles and flashbacks.. I'm staying tuned in and hope tomorow's episode will be just as thrilling as todays..
At 02:38 PM 10/15/2009 -0400, ssteinerX@gmail.com wrote:
that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). ...asked me who those team members are
I'm asking. Who are they and, if you are willing to give them access, have you offered it and they've declined, or you were waiting until...what? You had Tarek's acknowledgement or permission?
I am not trying to poach anyone or stir up trouble, which is why I've taken a very passive public stance on the issue -- although it has included me naming names in certain venues, including here.
However, I *am* in private contact with more than one member of the Distribute team, each of whom first contacted me.
In order to avoid creating any further drama here or in the Distribute team, I will leave it up to them to make any public statements, when/if they choose to confer with their colleagues on the matter. (I would prefer, of course, a joint statement at the appropriate time.)
I wish that such complications weren't necessary. If cooler heads had prevailed in July, this could have and likely would have been resolved back then.
We, regular Python users, have been asking for you to let someone help with setuptools for years since you obviously have other priorities and the various issues in setuptools have affected many of us in various ways.
The only reason I've done an 0.6c10 is because of a policy-breaking change to Python that breaks setuptools users, and that can't be worked around with configuration, command-line options, or other tweaking of the runtime environment -- as was able to be done with approximately 9 out of 10 of the setuptools bugs in the tracker.
If it weren't for that, I'd have been more-or-less happy to let Distribute become the quasi-official replacement for setuptools 0.6, despite my annoyance at some of the public comments made by its promoter(s) prior to the 2.6.3 issue.
Indeed, as previously stated, I even tried to arrange a handoff of 0.6, wherein the changes made in Distribute would've been released as 0.6c10 or 0.6final back in July... and public talks broke down due to certain persons' flaming and posturing.
That's one reason I'm only doing off-list talks now -- less chance of random jerks inserting themselves into the middle of the discussion, making me think they're part of Distribute and that their comments reflect Distribute policy (as also happened back in July). Also, no need for persons on either side to put up any posture or spin, when there's no audience to play to.
Are you really willing to let anyone help? Really?
Indeed. There's a list, and some of them obviously have time to work on Distribute, so it's not a matter of me only picking people who don't have any time, as Tarek and others have more than once accused me of.
Do it, then,
Discussions are ongoing.
Also, I've made it pretty plain for a long time that if Ian Bicking or Jim Fulton were ever willing to take it over, I'd hand it *all* over -- 0.7 as well as 0.6 -- and happily retire from the distribution tools business. I trust their vision as architects, and their track record of supporting their users IMO speaks for itself. Both are past contributors of non-trivial features to setuptools, as well as accomplished installation tool developers in their own right. It would be a joy and an honor to turn the keys over to either one of them, either as an individual or as the leader of a new team. (I would love to see some of pip and buildout's features integrated in setuptools 0.7, for example.)
(Ian, btw, already has PyPI maintainer rights to setuptools, and Jim already has commit rights to setuptools SVN... giving further lie to the idea that I'm not willing to give people access or let them help.)
That having been said, there are definitely other people I'd give varying degrees of access to, just not at the "here, take it, please, I want you to have it!" level I would grant to Ian or Jim. ;-)
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
participants (6)
-
david.lyon＠preisshare.net -
Michael Schurter -
P.J. Eby -
Reinout van Rees -
ssteinerX＠gmail.com -
Tarek Ziadé