[buildout] branches languishing? (site-packages and distutils scripts)
Hi All,
I'm wondering what the state of play is with the following branches:
reinout-scripts gary-4-include-site-packages
What more needs to happen for these to get merged to trunk and a release made?
cheers,
Chris
On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers chris@simplistix.co.uk 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.
gary-4-include-site-packages
afaik, Gary is reconsidering his approach. I'm not sure what the current status is.
Jim
On 01/19/2010 01:06 PM, Jim Fulton wrote:
On Tue, Jan 19, 2010 at 5:15 AM, Chris Witherschris@simplistix.co.uk 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
On Tue, Jan 19, 2010 at 11:00 AM, Reinout van Rees reinout@vanrees.org wrote:
On 01/19/2010 01:06 PM, Jim Fulton wrote:
On Tue, Jan 19, 2010 at 5:15 AM, Chris Witherschris@simplistix.co.uk 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
Jim
Jim Fulton jim@zope.com writes:
On Tue, Jan 19, 2010 at 11:00 AM, Reinout van Rees reinout@vanrees.org wrote:
On 01/19/2010 01:06 PM, Jim Fulton wrote:
On Tue, Jan 19, 2010 at 5:15 AM, Chris Witherschris@simplistix.co.uk 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 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 think I only had to call some setuptools function, basically.
Would it be an idea to move zc.buildout out of the zope svn repo into 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. And some extra outside effort into buildout would be nice.
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.
And... I'd love a list of current maintainers of zc.buildout that are allowed to commit to trunk. iirc Jim only works on the python 3 port ("1.5.x is too hard to understand now") 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?
Reinout
On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees reinout@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
On 25-03-12 19:39, Jim Fulton wrote:
On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Reesreinout@vanrees.org 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).
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 or virtualenv/pip? Quicker instead of trying to simplify the current code as such?
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 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"? :-)
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. See http://reinout.vanrees.org/weblog/2011/10/11/moving-svn-to-github.html for some tips and common errors.
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.
- Where to put it on github? Is there a zope or zope corp or Jim account that's the best place to put it?
Create a new branch from 1.4.4.
(Don't know the proper git terminilogy for this, as I don't know git yet. :)
Budget some time for a week of screaming, after that git works fine.
- Remove setuptools support (just use distribute).
Or distutils2? Or perhaps even pip? I don't know myself.
Then:
- Merge reinout-scripts :)
With some luck, after using distribute or whatever, the branch won't be needed anymore :-)
(Regarding helping: I'll definitively monitor this mailinglist more actively and jump in when possible. I'm however writing a Django book at the moment, so I *do* have time constraints. Note that I've already put a buildout chapter in my table of contents :-) )
Reinout
On Sun, Mar 25, 2012 at 10:12 PM, Reinout van Rees reinout@vanrees.org 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 4:12 PM, Reinout van Rees reinout@vanrees.org wrote:
On 25-03-12 19:39, Jim Fulton wrote:
On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Reesreinout@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
On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton jim@zope.com 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 hanno@hannosch.eu wrote:
On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton jim@zope.com 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.
Thanks!
Jim
On Sun, Mar 25, 2012 at 5:49 PM, Hanno Schlichting hanno@hannosch.eu wrote:
On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton jim@zope.com 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
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 hanno@hannosch.eu wrote:
On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton jim@zope.com 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.
Jonathan
On Sun, Apr 1, 2012 at 10:25 PM, Jonathan Ballet jon@multani.info 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 hanno@hannosch.eu wrote:
On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton jim@zope.com 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
On 01-04-12 21:30, Jim Fulton wrote:
I'm going to go outside and punch some holes in the ground.:)
Placing a trebuchet outside of github's headquarters and lobbing 2-century-old eggs at them is reported to be therapeutic, too.
Reinout
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 Reesreinout@vanrees.org 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
Le Sun, 25 Mar 2012 13:39:22 -0400, Jim Fulton jim@zope.com a écrit :
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 :)
FWIW, we (Nexedi) did it internally to include several fixes/changes we need, one branch per fix + merge back to "master" branch (aka trunk in svn terminology), all based on "upstream" branch (which is just buildout's trunk).
http://git.erp5.org/gitweb/slapos.buildout.git
Each bug-fixing/feature-adding branch is named after the corresponding launchpad bug number.
We didn't create branches nor tags corresponding to buildout releases & branches, as far as I can see. We would be happy to help converting the repository - and start hammering it with patches :) .
Regards,
On Mon, Mar 26, 2012 at 4:10 AM, Vincent Pelletier vincent@nexedi.com 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:
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.
OTOH, you don't need absolutely everyone. If you've just got the top 3 you've probably got most of the commits, I'd guess?
That's enough. It is just that if you've written 25% of a code base and your commits aren't tied to the account, that's a bit sad. Everyone ought to see that tracking down all emails is OK.
So just grab three or four and that's enough.
Reinout
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
On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees reinout@vanrees.org 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. 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.
Hanno
On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting hanno@hannosch.eu wrote:
On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees reinout@vanrees.org 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 4:38 PM, Jim Fulton jim@zope.com wrote:
On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting hanno@hannosch.eu 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".
Hanno
On Mon, Mar 26, 2012 at 10:45 AM, Hanno Schlichting hanno@hannosch.eu wrote:
On Mon, Mar 26, 2012 at 4:38 PM, Jim Fulton jim@zope.com wrote:
On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting hanno@hannosch.eu 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
On 01/19/2010 11:15 AM, Chris Withers wrote:
gary-4-include-site-packages
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.
Reinout
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 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 ?
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
participants (10)
-
Chris Withers -
Gary Poster -
Hanno Schlichting -
Jim Fulton -
Jonathan Ballet -
Marius Gedminas -
Reinout van Rees -
Ross Patterson -
Vincent Pelletier -
Yonsy Solis