[Grok-dev] Re: mars.* vs. grokcore.view, five.grok and releases

[Martin Aspeli]

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

http://pypi.python.org/pypi/plone.recipe.zope2install

Fake eggs are done on the Zope *install* not on the individual Zope 
instance.

> 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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book