[Grok-dev] Re: mars.* vs. grokcore.view, five.grok and releases
optilude at gmx.net
Sun Aug 3 11:59:27 EDT 2008
Philipp von Weitershausen wrote:
> Martin Aspeli wrote:
>> Martin Aspeli wrote:
>>>> five.grok OTOH still needs lot of love. I tried fixing it up as I
>>>> refactored the various grokcore.* packages, but lately I've been
>>>> struggling with the fake-eggs thing. Perhaps you can give it a go and
>>>> see where the problem is?
>>> I am going to have a go later today (in an hour or two) so yeah, I
>>> will, especially if you can tell me what is not working.
>>> I can probably help with fake-eggs as well if you need that.
>> I just checked in a fix to buildout.cfg in five.grok that make the tests
>> run. They all still pass. I had to force upgrade zope.component to 3.4
>> since it seems something is depending on a 'hook' option that it doesn't
>> have with fake eggs and Zope 2.10.6. :-/
>> I'm not quite sure this is necessary, but at least the tests pass now.
> Cool, thanks! I wasn't aware of the skip-fake-eggs option. I was looking
> for an option like that, but plone.recipe.zope2instance's PyPI page
> doesn't mention any support for fake eggs at all.
Because that's the wrong recipe... see
Fake eggs are done on the Zope *install* not on the individual Zope
> I saw you brought back buildout:eggs. Why? I see this a lot in Plone
> buildouts and I always wonder what it's for. AFAIK buildout:eggs isn't
> an official option supported by zc.buildout. Frankly, I find it
> confusing because it looks like it does something, but so far I couldn't
> figure out what it does.
The real reason is that I was fiddling with the buildout until I could
make it work. However, for buildouts like this where the whole thing is
about a single set of eggs (i.e. you want both the instance, the custom
interpreter and the test runner to work on the exact same working set),
I find it more natural to declare those at the top and re-use the
variable throughout. It's just a personal preference, though.
> I'm particularly puzzled that you included grokcore.security and
> grokcore.view in that option. Why? THey should just be picked up as
> dependencies of five.grok.
Yeah, I thought so too, but for some reason they weren't - or rather,
grokcore.security was missing in bin/test. I just wanted to get
something that worked checked in quickly, but we should try to take it
out again and work out if/why it fails to pick it up.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev