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

[Jim Fulton]

On Sun, Mar 25, 2012 at 4:12 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 25-03-12 19:39, Jim Fulton wrote:
>>
>> On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees<reinout at vanrees.org>
>> wrote:

...

>> 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>
>
>
> Perhaps a different way is quicker/easier?
>
> What I mean, if buildout is a big hairy complex wrapper around setuptools,
> perhaps it is easier to build it upon/around/with something else?
>
> We know what buildout does and how it does it, so perhaps it is quicker to
> make it use/wrap distutils2

Distutils2 has lots of issues. It also lacks things that buildout
wants, like, um, eggs...  It will become more solid with time, and we
can work around it's limitations, but trying to rely on it now
wouldn't be a good way to make progress.

> or virtualenv/pip?

That's both the wrong level of abstraction and an impedence missmatch.

> Quicker instead of trying to
> simplify the current code as such?

I'm pretty hopeful that starting with 1.4 will be sane.

> Buildout has some unique niceties like the recipes and a more explicit/solid
> installation experience than you'd get with virtualenv/pip. ("pip install
> something" ends up in your system, even when "bin/pip install something" was
> what you meant).
>
> But... is it technically possible to use/wrap virtualenv/pip and let them
> worry about the upcoming setup.py-to-setup.cfg change, for instance?

I really don't think that's a good idea.

>
>> 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.
>
>
> Well, you're the zope pope, so what about "buildout bishop"? :-)

Seriously, I think that model's broken.

What I meant above was that somebody (preferably somebodies) need to
protect simplicity.  I didn't mean to suggest that it had to be me.

>> 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 :)
>
>
> svn2git works fine.

I just made it work on my mac. (An attempt on ubuntu failed for some
unknown reason <shrug>.)  I now have a local repo. :)

> See
> http://reinout.vanrees.org/weblog/2011/10/11/moving-svn-to-github.html
> for some tips and common errors.

ok...

>
> There are two organizational things that needs to be done:
>
> - We need a mapping from zope svn usernames to email addresses (at least for
> buildout committers). Otherwise all the commits aren't credited (which would
> be a shame) as github identifies commits by email address.

Yup, I didn't do that. I can do that I guess.  I'll have to chase down
the committers emails...

> - Where to put it on github? Is there a zope or zope corp or Jim account
> that's the best place to put it?

I have a personal account.

Hanno suggested creating a buildout organization.  I'm up with that.
Maybe someone can create one and include me. :)

>> - Merge reinout-scripts :)
>
>
> With some luck, after using distribute or whatever, the branch won't be
> needed anymore :-)

distribute is just a setuptools clone. The branch will still be needed.

Jim

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