[Grok-dev] Grok and eggs

Martijn Faassen faassen at startifact.com
Fri Feb 20 14:07:12 EST 2009

Kim Luong wrote:
> Asked in #grok without an answer:
> When easy_installing grok 1.0a1, I get 
> zope.app.container-3.7.1-py2.4.egg in my site-packages, despite the fact 
> that versions.cfg specifies zope.app.container = 3.5.6. I know that 
> buildout is orthogonal to easy_install,

The proper way to install Grok is to use grokproject, which sets up the 
buildout for you. We're not supporting easy_install-ing grok at the 
moment - it'd need to do a lot of setup to work and buildout does that 
for us with recipes. Why are you trying to install grok with easy_install?

versions.cfg is a buildout specific conept. If we wanted to make Grok 
install the right versions with easy_install, we'd have to do one of two 

* lock down all versions in Grok's setup.py. There are great benefits in 
allowing users to override these versions however, which the 
versions.cfg of buildout allows us. The versions.cfg list is a set of 
suggestions which we make sure will work. If you for your project for 
some reason have to deviate from this, you can, however.

* have a custom package index page and tell people to easy_install from 
this index. The index would only make available those versions that we 
recommend. This would still stop people from choosing to use different 
versions if they should wish so, however. Grok's versions.cfg approach 
doesn't have this problem. I'm sure there are ways around this with 
custom indexes too, but the approach Grok took works well enough for us.

easy_install by itself to my knowledge has no way to instruct it to use 
a particular list of versions. For this you'd need to use buildout or a 
easy_install alternative like pip, or a custom index would need to be used.

 > but does this mean grok has to
 > be installed using buildout and not using easy_install or setup.py
 > dependencies?

Yes, you should install Grok using setuptools and not using 
easy_install. You can depend on grok using setup.py dependencies, but 
you'd need to supply some way to restrict which versions of dependencies 
get installed yourself.

Given the toolset we have this is the best balance we have between 
flexibility and stability. It'd be nice if suggested "known-good" 
versions could be indicated directly in setup.py itself, with setuptools 
awareness of this. Then we could ship a list of suggestions inside Grok 

If you just want to use bits of Grok, such as grokcore.component, you 
can probably get away with just using the most recent versions of 
dependencies as they don't change very quickly. For other bits of grok, 
such as grokcore.security and grokcore.view, the situation is that they 
pull in a lot of dependencies. We're hoping to get this fixed in the 
Grok 1.1 era (we already started work on cleaning up the underlying 

For more of my thinking about this topic see here:




More information about the Grok-dev mailing list