[Grok-dev] Re: Making an egg bundle for Grok

[Maurits van Rees]

Philipp von Weitershausen, on 2008-05-17:
> Maurits van Rees wrote:
>> Hi fellow grokkers!
>> 
>> Out of the Grokkerdam sprint z3c.recipe.eggbasket was born.  This lets
>> you quickstart a grok project by first installing the grok egg and its
>> dependencies from a tar ball without relying on a zillion cheese shops
>> and sourceforges, like this:
>> 
>> [eggbasket]
>> recipe = z3c.recipe.eggbasket
>> eggs = grok
>> url = http://grok.zope.org/releaseinfo/grok-eggs-0.12.tgz
>
> Just to make sure, this recipe will do nothing if whatever you specified 
> in 'eggs' was already installed, right?

Right.  In fact the 'upgrade' method of that recipe explicitly does
nothing.  And the 'install' method checks to see if the right grok
version plus dependencies are already available in your shared eggs
directory, in which case it will not download the tarball either.

>> It has a buildout.cfg for testing.  The important part is this, which
>> you could add to any random buildout (say the grok one):
>> 
>> [releasemaker]
>> recipe = zc.recipe.egg
>> eggs = z3c.recipe.eggbasket
>> arguments =
>>     egg = 'grok',
>>     versionfile = 'http://grok.zope.org/releaseinfo/grok-0.12.cfg'
>> 
>> This is slightly awkward: note the comma and the quotes that are
>> needed in the arguments.  But it does the trick.
>
> Right. This is a trick that works when you have regular console_scripts 
> that you want to pimp up with arguments from buildout.cfg. However, this 
> script that you're providing (currently called releasemaker) really only 
> works within a buildout anyway, right?

It should not really need a buildout.  If you just easy_install the
package, you will get that script.  Then you give that script the name
of an egg and the location of a buildout.cfg or simply a versions.cfg
and it will figure it out.  No buildout directory is needed, although
zc.buildout itself is a dependency.

There is the minor detail that the script does not currently accept
command line parameters, but that should be easy enough to change.

But the only piece of software I know that actually knows what to do
with the resulting tarball is the eggbasket recipe in that same
package, which definitely needs to be in a buildout.cfg, so a do not
expect a quick adoption by the buildout-less part of the python world.

> So I suggest writing a small 
> recipe that installs the script, that way the parameter configuration 
> could be a bit nicer:
>
> [bundlemaker]
> recipe = z3c.recipe.eggbasket#bundlemaker
> eggs = grok
> versionfile = http://grok.zope.org/releaseinfo/grok-0.12.cfg

That would be better yes.  I'll see about doing something like that.

>> Naming suggestions for the script are also welcome: releasemaker,
>> releaser, eggbasket, create_egg_bundle, shipit, etc.
>
> I think releasemaker is a bit besides the point. It doesn't really make 
> a release, does it. It makes a bundle of a bunch of released stuff, so 
> bundlemaker or make-eggbasket or whatever seems like a better name.

I was thinking of calling it 'motherhen', a script that collects eggs
and watches over it like a mother hen.  Might be a bit too cryptic
though. ;-)

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]