[Grok-dev] Re: solving buildout problems - pinning down eggs

[Martin Aspeli]

Martijn Faassen wrote:
> Hey,
> 
> Wichert Akkerman wrote:
> [snip]
>> plone.recipe.plone does exactly that for Plone. Its implementation is
>> very tied to the way the Plone release-creation-scripts work (horribly)
>> but it solves this problem very well. You can see how it works on its
>> cheesehop page.
> 
> Thanks for the reference to the cheeseshop page. For convenience to 
> other readers, here's the link:
> 
> http://cheeseshop.python.org/pypi/plone.recipe.plone
> 
> This would code this information into the recipe though, if I understand 
> it correctly. This would involve releasing a new recipe each time a new 
> version of grok is released, correct?

Yes it does. This is not ideal, but was the best way in the interim 
until we can refactor the Plone release management tools (which mainly 
drive installers).

In the future, it should be:

[plone]
recipe = plone.recipe.plone
version = 3.0.1

Most of the recipe would work the same to support this syntax. All we 
need is an indepenent means of listing what 'release 3.0.1' is. In the 
Plone world, that probably means eggifying dist_plone, the package that 
keeps track of all the versions for a release. For Grok, creating such a 
canonical list that can be downloaded by the recipe should be easy.

> I'd prefer just to do a release of grok and have everything Be Right. I 
> think that the grok package should know about the dependencies anyway - 
> if you install grok 0.10, you expect to get a lot of code that works for 
> grok 0.10. I'd like reproducibility - you get the exact same versions of 
> everything on each installation.

+1

plone.recipe.plone does let you explicitly override versions (pass an 
'eggs' option), which I think is important, but it strongly prefers 
"known good".

> I was thinking about writing a recipe that can produce a list of 
> dependencies (unfolded) for a particular egg. This output could then be 
> used to place it in the dependencies section of setup.py.

Please do look at the plone.recipe.plone implementation. Also, look at 
the debate Philipp started a couple of weeks ago about known-good 
working sets in buildout. He had a solution using 'versions' sections.

> Drawback of course is that these can't be overridden. Alternatively, if 
> buildout grows a new feature, we could have a dependency_suggestions 
> section in the setup.py, which can be overridden (somewhere. details 
> still missing).

Again, please study plone.recipe.plone. It allows overrides. Apart from 
the recipe-release-per-plone-release nuisance, it works well, and hides 
many of the iffy issues from end users.

Martin

-- 
Acquisition is a jealous mistress