[Distutils] [buildout] branches languishing? (site-packages and distutils scripts)
jim at zope.com
Sun Mar 25 19:39:22 CEST 2012
On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 24-03-12 20:56, Ross Patterson wrote:
>> Can we possibly get this branch merged and a release made?
> From what I remembered from 2.5 year ago was that the fix was pretty small.
I guess that depends on what you men by small. I don't consider the
change small. I would call it straight forward.
I wish this had gotten merged before the 1.5 changes. I'm sorry.
> I think I only had to call some setuptools function, basically.
Looks like more than that.
> Would it be an idea to move zc.buildout out of the zope svn repo into
Yes. In fact, I was just looking at that. Github's review mechanism
is particularly attractive.
(AFAICT, bitbucket doesn't have a review/comment process like
github's. All I see is the ability to accept or reject pull
requests. I only know either from reading docs. If I'm mistaken,
please correct me, as the review process is what makes me lean toword
> It is quite central to many non-zope projects and nobody outside of
> zope is going to bother with a contributor agreement, I think.
Yes, although I don't think that's the main problem.
(Don't argue this with me, it's just an opinion. :)
> And some
> extra outside effort into buildout would be nice.
Absolutely. I think the code needs a drastic simplification to enable
> A good thing about github (or xxx or yyy) would be the ease of pull
> requests. And a pull request coupled with a visible bug report "scripts
> don't work" stands more chance of being included than a 2.5 year old simple
> fix in some branch with some old mailinglist messages.
Not sure about that. I think the integrated review support would
definitely be accretive.
> And... I'd love a list of current maintainers of zc.buildout that are
> allowed to commit to trunk.
Um, any svn.zope.org committer is technically allowed. I realize
that's not what you're asking, but ...
> iirc Jim only works on the python 3 port
Not intentionally. :)
> is too hard to understand now")
Unfortunately, the Python 3 port (aka buildout2) was based in
trunk/1.5. I don't understand it either. ;)
I spent a few hours yesterday poking at the 2 branch trying to find a
way to attack simplifying it. My suspicion is that it would be easier
to start from 1.4, although that will require redoing the Python 3
As an aside, I'm wrapping up an OS project that I've been working on
for the past few months, so I'm ready to spend some focussed time on
> and the 1.5.x trunk itself hasn't seen any
> development lately as far as I could see, despite people being stuck on
> 1.4.x. So... who's maintaining buildout right now?
Theoretically, I am, as are various helpers. Thomas Lotze put in a
bunch of work last year trying to help me clean up the 2 branch. I
appreciate his efforts, but it wasn't enough....
A little bit was done on the trunk (and ported to the 2 branch) in a
sprint last fall.
I would love to move to a more team-based approach. I really don't
want to be in charge. I certainly don't want to be a blocker. OTOH,
someone will beed to protect simplicity, if we ever achieve it.
I think to make contributors more effective, we have to simplify the
code a lot. (We also need better docs, but that's another issue.)
Here's a possible plan:
- Create a github repo from svn.
Not sure the best apprach to this. I was thinking of using svn2git
to copy the zc.buildout svn project.
Someone with git foo could help with this, although this wants to be
soon. (Like nowish :)
- Create a new branch from 1.4.4.
(Don't know the proper git terminilogy for this, as I don't know git
- Remove support for multiple Python interpreters in a single
- Remove setuptools support (just use distribute).
- Think of ways to simplify the code, or more importantly, the tests.
Maybe provide some test infrastructure to make setup and assertions
At this point, I think it should be easier for people to contribute.
- Merge reinout-scripts :)
- Change some defaults (always unzip, prefer final, etc.)
- maybe rename the project to buildout, thus avoiding backward
- Release buildout 0.1 (not zc.buildout).
- Port to 2&3 (one codebase as was done for the 2 branch).
- Cherry pick changes since 1.4.4.
This would, of course, include better interaction with system
- Simple isolation from site customization (ala -S),
- Better behavior when not isolated (recognize and don't override
- Better failure. When not isolated and something goes wrong give
better error messages.
- Work with virtualenv.
This needs to be done more simply than what was done in
1.5. (Again, FTR I appreciate the huge effort that went into 1.5.)
I have some ideas for this.
Releasing along the way.
- New hotness (and releases)!
- Somewhere along the line, when we think we aren't going to break
things for a while, release 1.0.
- Port to d2/p.
Thoughts? Anyone wanna help (take over :)? Wanna maybe sprint via IRC?
P.S. I'm happy to let someone else (preferably a team) be in charge,
but I have no intention of washing by hands of buildout.
More information about the Distutils-SIG