On 01/19/2010 01:06 PM, Jim Fulton wrote:

On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers wrote:

...

Hi All,

I'm wondering what the state of play is with the following branches:

reinout-scripts

Not sure. I need to review this.

Do you need me to make a fresh branch off the current trunk? The changes were pretty isolated in one spot if memory serves me. Only possibly tricky bit is the test I added for it: the only practical way I could find to test it was to add an old-style script to one of the existing demo test packages. iirc. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Programmer/advisor at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets"

Jim Fulton writes:

On Tue, Jan 19, 2010 at 11:00 AM, Reinout van Rees wrote:

...

On 01/19/2010 01:06 PM, Jim Fulton wrote:

...

On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers  wrote:

...

Hi All,

I'm wondering what the state of play is with the following branches:

reinout-scripts

Not sure. I need to review this.

Do you need me to make a fresh branch off the current trunk?

No

I've run into the problem of buildout not installing distutils `scritps` many times. This means I can't use buildout when I would like to. It's also worth noting that pip handles this properly. At the moment, I'm writing a buildout tutorial whose aim is to help developers using Python understand the utility and core concepts of buildout. It's really unfortunate I can't tell them to do use the following `buildout.cfg` to get the `docutils` scripts in an isolated buildout: [buildout] parts = docutils [docutils] recipe = zc.recipe.egg Can we possibly get this branch merged and a release made? Ross

On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees 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

On Sun, Mar 25, 2012 at 10:12 PM, Reinout van Rees wrote:

- 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'd suggest the creation of a separate buildout organization. Such a place might over time also get a collection of various recipes, zc.recipe.egg / zc.recipe.cmmi being prime examples. There is a non-sanctioned https://github.com/zopefoundation which I have control of. But as there's really nothing Zope specific about buildout, I wouldn't want to continue associating it with Zope. Hanno

On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote:

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

In case you want it, there you go: https://github.com/buildout/buildout Jim is a co-owner of the organization having admin access, the developers team with pull/push rights is currently empty. Hanno

On Sun, Mar 25, 2012 at 5:49 PM, Hanno Schlichting wrote:

On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote:

...

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

In case you want it, there you go: https://github.com/buildout/buildout

OK, I've populated this. I: 1) Got rid of some old svn branches that were allready merged or abandoned. 2) Ran svn2git This hurt. Your ~/.svn2git/authors file has to be complete or the conversion stops before completion. For people who didn't respond to my spam for git emails, I had to make due with svn.zope.org repo emais. svn2git copied branches that were deleted in svn. I deleted the junk branches in git. After much flailing and with some help, I removed some bogus remote tracking branches created by svn2git that made working with the other branches difficult. The master branch corresponded to the svn trunk. I renamed it to svntrunk. Since I intend to start new work from the 1.4 trunk, I made a new master from that. I set up git@github.com:buildout/buildout.git as the origin remote and pushed to it with -u and --all. Everything seems to be there. :) Maybe someone can check my handiwork. I'm going to go outside and punch some holes in the ground. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On Sun, Apr 1, 2012 at 10:25 PM, Jonathan Ballet wrote:

Hi Jim,

On Sun, Apr 01, 2012 at 03:30:06PM -0400, Jim Fulton wrote:

...

On Sun, Mar 25, 2012 at 5:49 PM, Hanno Schlichting wrote:

...

On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote:

...

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

In case you want it, there you go: https://github.com/buildout/buildout [...] Maybe someone can check my handiwork.

Thanks for the import, this is really cool!

You might want to also push the tags to Github. Git doesn't push the tags by default, so you also need to specify "--tags" to your "git push" command.

Thanks. Done. I guess --all means --some. Sigh. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On Sun, Mar 25, 2012 at 10:12:30PM +0200, Reinout van Rees wrote:

On 25-03-12 19:39, Jim Fulton wrote:

...

On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees wrote:

...

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.

Yep. Comment on entire pull requests, individual commits and individual lines. Works well. (Only real github problem I found is lack of attachments (=screenshots) in issues, but that's not something that ought to bother buildout).

For the record, screenshots on issues are possible. Here's an example: https://github.com/mgedmin/SnakeMUD/issues/2 The caveat is that you have to upload them somewhere else (e.g. http://imgur.com), and just link to them on GitHub (using Markdown if you want it displayed inline). And, of course, Imgur will delete images if they're rarely accessed, which hasn't happened to me yet, but worries me sometimes. Marius Gedminas -- America and England are two countries separated by a common language.

On Mon, Mar 26, 2012 at 4:10 AM, Vincent Pelletier wrote:

Le Sun, 25 Mar 2012 13:39:22 -0400, ... We would be happy to help converting the repository -

Thanks. So, I guess the first step is to gather git ids for past contributors. :/ I can work on this. I suppose then it's a matter of running svn2git, which I've already done successfully once. Question for everyone interested, do you think I should copy the whole zc.buildout project, and thus its history? Or would it be better to start a new project based on the 1.4 branch (or 1.4.4 tag)? The later would be simpler, as I wouldn't have to chase down (often non-existent) git ids for past contributors. Does anyone have any objections to renaming the project "buildout"? I expect that most existing recipes would work with the new buildout. Recipes that import zc.buildout (zc.buildout.easy_install) would be broken. Those recipes would be likely to be broken by changes we'd make (like omissions of the new 1.5-based APIs) anyway. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On 26-03-12 13:41, Jim Fulton wrote:

Does anyone have any objections to renaming the project "buildout"? I expect that most existing recipes would work with the new buildout. Recipes that import zc.buildout (zc.buildout.easy_install) would be broken. Those recipes would be likely to be broken by changes we'd make (like omissions of the new 1.5-based APIs) anyway.

Rename is fine with me. And if needed we can mock a zc.buildout inside it to help with moving over, I'd guess. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham"

On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting wrote:

On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees wrote:

...

On 26-03-12 13:41, Jim Fulton wrote:

...

Does anyone have any objections to renaming the project "buildout"?

Rename is fine with me.

+1

But there's about 20 or so packages on PyPi using buildout as a namespace package.

Gaaaa. I wasn't aware of that.

That'll work just fine, as long as the new buildout puts the magic into its top level __init__.py and has no other code there.

No, it won't. You can't count on the order that namespace packages get scanned, so you really can't have code in __init__.py if you want to count on it getting installed. This needs more thought. The new buildout could be a subpackage of the buildout namespace, although that seems awkward. Maybe it would be best to stick with zc.buildout 2.x. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On Mon, Mar 26, 2012 at 10:45 AM, Hanno Schlichting wrote:

On Mon, Mar 26, 2012 at 4:38 PM, Jim Fulton wrote:

...

On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting wrote:

...

That'll work just fine, as long as the new buildout puts the magic into its top level __init__.py and has no other code there.

No, it won't. You can't count on the order that namespace packages get scanned, so you really can't have code in __init__.py if you want to count on it getting installed.

That's my point. As long as every buildout/__init__.py contains the setuptools namespace code and nothing else, all is fine. So as long as the new buildout distribution does the same, it'll all work.

I'm not aware of any problems with having modules directly inside a namespace package. So a buildout/easy_install.py should be importable via "from buildout import easy_install".

OK, right that's supposed to work. Let's try it. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

On Jan 19, 2010, at 11:08 AM, Reinout van Rees wrote:

On 01/19/2010 11:15 AM, Chris Withers wrote:

...

gary-4-include-site-packages

I'm getting back to this this week. The new branch is svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-4 . It has most of what I intend but needs a bit more work. It could be ready for Jim's review this week.

include-site-packages branch: from what I see in the changelog (http://tinyurl.com/y9x27oj), this would mean that a globally installed package is found by buildout/setuptools' dependency handling?

So if I install PIL with debian's apt-get, buildout doesn't attempt to grab another copy from pypi? Unsure about that from reading the changelog.

The old branch supported that, with the right buildout configuration, and if apt-get installed the package as an egg. The new branch does not try for that. It simply builds dependency sets ignoring the Python's site.py (so, ignoring site-packages). If desired, you can have scripts import site.py *after* the buildout eggs have been set up (so if your buildout did not require PIL, but your system's Python had it, your code could use the system's version if you were willing to open yourself up to that potential fragility), but that's the only integration. If it is really desired, I could look at porting the work later from the previous branch (after the basic work on the new approach lands). I am currently of the opinion that it is too tricky for too rare of a win (and I don't need it right now ;-) ). Gary

On Jan 19, 2010, at 12:08 PM, Yonsy Solis wrote:

On Tue, 2010-01-19 at 11:29 -0500, Gary Poster wrote:

...

The new branch does not try for that. It simply builds dependency sets ignoring the Python's site.py (so, ignoring site-packages). If desired, you can have scripts import site.py *after* the buildout eggs have been set up (so if your buildout did not require PIL, but your system's Python had it, your code could use the system's version if you were willing to open yourself up to that potential fragility), but that's the only integration.

If it is really desired, I could look at porting the work later from the previous branch (after the basic work on the new approach lands). I am currently of the opinion that it is too tricky for too rare of a win (and I don't need it right now ;-) ).

Gary, exist any way that this feature to exclude the site-packages can be coded like an buildout extension ?

Not that I see, no. It needs changes that are at the heart of the buildout code, AFAIK. Gary