Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote:
While it's great to have Philipp being part of our distutils design discussions, for his experience, I am not concerned of not having him in this "internal consensus" since Setuptools is not maintained anymore.
He said some months ago, he would work on a brand new setuptools version with zero dependency to distutils. But it's still vaporware (from his own words), and the previous version is unmaintained for a year, so it was forked.
Here's what actually happened, if anyone cares. Tarek and friends announced a fork of setuptools. I reviewed the work and saw that -- for the most part -- I was happy with it, and opined as how I might be willing to bless the the "package inquisition" team as official maintainers of the 0.6 branch of setuptools, so that I could work on the fun bits I've long planned for 0.7, but never felt free to start on while there was so much still needing to be done on 0.6. However, just as I mentioned this, and suggested an option for what I could do that would be helpful to his Distribute 0.7 project as well as various other tools (e.g. implementing some of Jim Fulton's long-requested features for better modularization of setuptools), Tarek accused me of somehow trying to undermine his plans. In addition, it appears Tarek was also offended by my earlier statement that there were only a few people in the Python community who had *already* earned my implicit trust to not only hack on setuptools unsupervised, but also to take over its *future* direction and BDFL-ship. (For example, Jim Fulton and Ian Bicking.) Tarek, however, appears to have taken this to mean that I personally thought he was an incompetent programmer or something (when I actually had no opinion one way or the other), and ever since he has taken to levelling potshots like the above at me on a semi-regular basis. I've tried to ignore this and play nice, because he is actually working on this stuff and I am not. But it's hard for me to actually give any help in practice, if Tarek is too busy projecting hidden plots onto everything I say and do. If you read Tarek's distutils-sig posts, it appears my already-existing trust in Ian and Jim was not only a personal insult to Tarek, but also a plot to ensure that nobody with any time to do so would ever work on setuptools, just as my excitement about working on setuptools again was a plot to steal thunder from his fork. All I want is for good stuff to happen for setuptools users and Python users in general, so I don't think all the suspicion and backbiting is merited. I certainly don't appreciate it, and I would like it to stop. It also isn't even relevant to the thread, since my lack of work on setuptools says exactly zero about the merits or lack thereof of Tarek's proposals for the distutils! Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't even object to him Pronouncing it or cutting off the discussion! My only issue on Python-Dev was his inaccurate implication that it was a SIG consensus rather than a pronouncement on it. There is and was no need for any of this to get personal, and I have continually strived to keep my posts here and distutils-sig civil, even when I didn't feel like being civil in response to Tarek's jabs. I have in fact bent over backwards to be *nice* to Tarek, because he seemed so damn sensitive about everything. Apparently, however, this does not actually help things. :-(
P.J. Eby <pje <at> telecommunity.com> writes:
Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't even object to him Pronouncing it or cutting off the discussion! My only issue on Python-Dev was his inaccurate implication that it was a SIG consensus rather than a pronouncement on it. There is and was no need for any of this to get personal, and I have continually strived to keep my posts here and distutils-sig civil, even when I didn't feel like being civil in response to Tarek's jabs. I have in fact bent over backwards to be *nice* to Tarek, because he seemed so damn sensitive about everything. Apparently, however, this does not actually help things.
Ok, so Tarek and Philip, are you both ok that those little disagreements should belong to the past now? :) Philip did an important job in bringing setuptools to the Python community, and Tarek took a difficult decision when he finally decided to fork setuptools (he had probably been privately encouraged for months by people like me, and was still reluctant to do it AFAICT). Both of you have been tremendously helpful to Python, and I'm sure we can move forward graciously. Regards Antoine.
Fine with me. Let's move forward. On Sep 23, 2009 11:27 PM, "Antoine Pitrou" <solipsis@pitrou.net> wrote: P.J. Eby <pje <at> telecommunity.com> writes: > > Hell, I *support* the bulk of Tarek's setup.cfg p... Ok, so Tarek and Philip, are you both ok that those little disagreements should belong to the past now? :) Philip did an important job in bringing setuptools to the Python community, and Tarek took a difficult decision when he finally decided to fork setuptools (he had probably been privately encouraged for months by people like me, and was still reluctant to do it AFAICT). Both of you have been tremendously helpful to Python, and I'm sure we can move forward graciously. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http...
P.J. Eby wrote:
Here's what actually happened, if anyone cares. Tarek and friends announced a fork of setuptools. I reviewed the work and saw that -- for the most part -- I was happy with it, and opined as how I might be willing to bless the the "package inquisition" team as official maintainers of the 0.6 branch of setuptools, so that I could work on the fun bits I've long planned for 0.7, but never felt free to start on while there was so much still needing to be done on 0.6.
If this offer is still available, I'd lake to take you up on it. I'd be more than willing to merge changes on the 0.6 distribute branch back into the setuptools codebase and do whatever is needed to get a new setuptools release out. Why? Because there are a *lot* of copies of ez_setup.py and buildout's bootstrap.py that will need replacing if it doesn't happen. I think it'd be better for the python community all round if setuptools just continued in maintenance mode until whatever-ends-up-in-the-core exists and people want to use... I'm happy to submit to whatever supervision is needed for you to trust me to do this, and I promise to be as careful as I can with this. I *know* how important this is and want to make it work...
All I want is for good stuff to happen for setuptools users and Python users in general, so I don't think all the suspicion and backbiting is merited.
Fine, if that's true, I apologize (even spelled correctly!) for any previous involvement in this, but please help me help you achieve your aims... To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can. Again, I feel I need to stress that the *only* reason I want to do this is to bring the benefits of the distribute work to the existing setuptools codebase, with appropriate attribution if that makes a difference. Apologies if any of this is offensive to anyone. For once (really!) I really mean that :-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Phil, It's almost a week since I made this offer. I haven't heard anything from you. If I've missed anything please let me know and I'll track it down, otherwise I hope you can have a look at this some time soon. cheers, Chris Chris Withers wrote:
P.J. Eby wrote:
Here's what actually happened, if anyone cares. Tarek and friends announced a fork of setuptools. I reviewed the work and saw that -- for the most part -- I was happy with it, and opined as how I might be willing to bless the the "package inquisition" team as official maintainers of the 0.6 branch of setuptools, so that I could work on the fun bits I've long planned for 0.7, but never felt free to start on while there was so much still needing to be done on 0.6.
If this offer is still available, I'd lake to take you up on it. I'd be more than willing to merge changes on the 0.6 distribute branch back into the setuptools codebase and do whatever is needed to get a new setuptools release out.
Why? Because there are a *lot* of copies of ez_setup.py and buildout's bootstrap.py that will need replacing if it doesn't happen. I think it'd be better for the python community all round if setuptools just continued in maintenance mode until whatever-ends-up-in-the-core exists and people want to use...
I'm happy to submit to whatever supervision is needed for you to trust me to do this, and I promise to be as careful as I can with this. I *know* how important this is and want to make it work...
All I want is for good stuff to happen for setuptools users and Python users in general, so I don't think all the suspicion and backbiting is merited.
Fine, if that's true, I apologize (even spelled correctly!) for any previous involvement in this, but please help me help you achieve your aims...
To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.
Again, I feel I need to stress that the *only* reason I want to do this is to bring the benefits of the distribute work to the existing setuptools codebase, with appropriate attribution if that makes a difference.
Apologies if any of this is offensive to anyone. For once (really!) I really mean that :-)
cheers,
Chris
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.
That may not be as easy as it sounds; Distribute deleted various things from the setuptools tree (e.g. the release.sh script, used for issuing releases) and of course it adds other stuff (e.g. stuff to overwrite setuptools). So you'd need to screen the diffs. Second, I still intend to move setuptools 0.7 forward at some point, which means the patches also need to go to the trunk. If I had the time to co-ordinate and supervise all this, I'd have the time to just do it myself. If you want to help with that, the most helpful thing would be for you to consolidate all the changes into a pair of patches: one for the 0.6 branch and one for the 0.7 trunk. These patches would also need to exclude the SVN 1.6 changes (as I already have a change for that in my working copy, not yet checked in). They would also need to include appropriate changelog and documentation updates. If you can get those to me by Friday, I'll have them reviewed, applied, and released by Monday. I was already planning to spend a little time on bug closing and patch application this coming weekend, so if you can do this for me first, it will maximize the number I can get done.
On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.
That may not be as easy as it sounds; Distribute deleted various things from the setuptools tree (e.g. the release.sh script, used for issuing releases) and of course it adds other stuff (e.g. stuff to overwrite setuptools). So you'd need to screen the diffs.
Second, I still intend to move setuptools 0.7 forward at some point, which means the patches also need to go to the trunk.
Dream on.
If I had the time to co-ordinate and supervise all this, I'd have the time to just do it myself.
I think at this point the community should not be forced wait for you to get a new supply of round tuits. The wait has been too long already. You can stay on in an advisory role, but I don't think it's reasonable to block development or decisions until you have time.
If you want to help with that, the most helpful thing would be for you to consolidate all the changes into a pair of patches: one for the 0.6 branch and one for the 0.7 trunk.
These patches would also need to exclude the SVN 1.6 changes (as I already have a change for that in my working copy, not yet checked in). They would also need to include appropriate changelog and documentation updates.
If you can get those to me by Friday, I'll have them reviewed, applied, and released by Monday. I was already planning to spend a little time on bug closing and patch application this coming weekend, so if you can do this for me first, it will maximize the number I can get done.
That's great, but I don't think it solves the structural problem, which is that you don't have enough time to devote to the project. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Oct 6, 2009 at 2:16 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Oct 6, 2009 at 11:03 AM, P.J. Eby <pje@telecommunity.com> wrote:
At 02:45 PM 10/6/2009 +0100, Chris Withers wrote:
To put this into a way that makes sense to me: I'm volunteering to keep distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and keep that as uncontroversial as possible, and get setuptools 0.6 releases out to match distribute 0.6 releases as soon as I can.
That may not be as easy as it sounds; Distribute deleted various things from the setuptools tree (e.g. the release.sh script, used for issuing releases) and of course it adds other stuff (e.g. stuff to overwrite setuptools). So you'd need to screen the diffs.
Second, I still intend to move setuptools 0.7 forward at some point, which means the patches also need to go to the trunk.
Dream on.
If I had the time to co-ordinate and supervise all this, I'd have the time to just do it myself.
I think at this point the community should not be forced wait for you to get a new supply of round tuits. The wait has been too long already. You can stay on in an advisory role, but I don't think it's reasonable to block development or decisions until you have time.
Is it possible to fork `setuptools` somehow ? This way : - patches may be built for setuptools 0.7 if it evolves - community can continue development in the «new» branch. all this easy if a DVCS is used ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Nabble - Trac Users - Coupling trac and symfony framework - http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-an...
On 6 Oct, 2009, at 21:56, Olemis Lang wrote:
Is it possible to fork `setuptools` somehow ? This way :
Yes, see <http://pypi.python.org/pypi/distribute> Ronald
participants (7)
-
Antoine Pitrou -
Chris Withers -
Guido van Rossum -
Olemis Lang -
P.J. Eby -
Ronald Oussoren -
Tarek Ziadé