On Aug 27, 2010, at 4:23 AM, Reinout van Rees wrote:
On 08/27/2010 02:31 AM, Gary Poster wrote:
Only the script recipe seems to support it at the moment and it didn't look from the documentation that such a globally-found dependency would be valid for the entire buildout (and all the other parts). If I use that osc.recipe.sysegg and list that part first, it makes sure all other parts use the specified system eggs.
But then you are susceptible to many problems that occur in system Pythons that I've been debugging for this release.
Ok, you're trying to tell me not to do something, only I don't know what that "something" is :-)
:-) Fair enough. Here's my message. I realize that a system Python happened to work for you before. That's a bit awkward, because with pre-1.5.0 zc.buildout, using a system Python was not supported. Therefore, your recipe was not supported. Happily, zc.buildout does support a system Python. Moreover, it is designed to support your use case. Unhappily, your previously unsupported recipe does not work with it. Also unhappily, you can't switch to the 1.5 line until enough recipes have changed to make it possible for you to use it. For now, then, yay Buildout 1.4.4! Eventually, yay, you will be able to fulfill your recipe's use cases in a way that is much more robust against various things that can happen in a system Python!
Do you mean it is a bad idea to use "matplotlib from the system packages" for the whole buildout? That it is better just to use it in the two or three parts where it is needed?
It needs to be possible to do this.
It's not like I want my system matplotlib in one part and a locally failing-horribly buildout-installed matplotlib in another part.
No, but single buildouts are used to install different sections with entirely different requirements, including different Python versions.
The current implementation makes it look like every single part that needs the system matplotlib needs to have a configuration for "look in the system for matplotlib".
Yes, parts are individually installed, per my statement above. That said, I generally think it is a good idea for recipes to look in the buildout section for defaults to the pertinent options. That's what z3c.recipe.scripts does, and that's what I intend to do for the other recipes I upgrade. That means that, effectively, you would be able to make a single gesture in your buildout section and other parts will honor it.
Ah! Did I perhaps misunderstand the 1.5.x changes? I'm used to have osc.recipe.sysegg pick two or three specific system eggs and add just those to the sys.path. Does the 1.5.x functionality only have a generic switch to switch on ALL system eggs?
No. As mentioned before, the documentation for http://pypi.python.org/pypi/z3c.recipe.scripts should give you an idea on the features. Please see the options include-site-packages and allowed-eggs-from-site-packages in particular.
I'm getting lost :-)
Which django recipe do you use, by the way? I intend to update djangorecipe, using some changes that Attila made.
Cool, that's the one.
Just a minute ago, I tried experimenting with a z3c.recipe.egg part mentioned as the first one, but I got an "ImportError: Entry point ('zc.buildout', 'default') not found".
If you can help me dupe, I'm happy to look at it.
I'll look in to it after next week. Two sites have a deadline then. So I'm happy with the 1.4.x-only bootstrap.py :-)
Cool. :-) Gary