[Distutils] [buildout] branches languishing? (site-packages and distutils scripts)

[Jim Fulton]

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
> github?

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
 github.)

> 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
that.

> 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. :)

> ("1.5.x
> 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
port. <whimper>

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
buildout.

> 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
  yet. :)

- Remove support for multiple Python interpreters in a single
  buildout.

- 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
  easier.

At this point, I think it should be easier for people to contribute.

Then:

- Merge reinout-scripts :)

- Change some defaults (always unzip, prefer final, etc.)

- maybe rename the project to buildout, thus avoiding backward
  compatibility issues.

- Release buildout 0.1 (not zc.buildout).

- Port to 2&3 (one codebase as was done for the 2 branch).

- Release.

- Cherry pick changes since 1.4.4.

  This would, of course, include better interaction with system
  Pythons including:

  - Simple isolation from site customization (ala -S),

  - Better behavior when not isolated (recognize and don't override
    system-installed projects),

  - 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.

Later

- Port to d2/p.

Thoughts? Anyone wanna help (take over :)? Wanna maybe sprint via IRC?

Jim

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.

--
Jim Fulton
http://www.linkedin.com/in/jimfulton