[Grok-dev] grok in the egg universe

[Martijn Faassen]

Hi there,

I've just been looking a little bit into how various buildouts on 
svn.zope.org work. Some of them declare their dependencies in setup.py 
and have very minimal buildout.cfg. This is a good example:

http://svn.zope.org/z3c.schema/trunk/

Its buildout.cfg is just:

[buildout]
develop = .
parts = test

[test]
recipe = zc.recipe.testrunner
eggs = z3c.schema [test]

And its setup.py lists the following dependencies:

       extras_require = dict(test=['zope.testing',
                                   ]),
       install_requires = ['setuptools',
                           'zope.i18nmessageid',
                           'zope.interface',
                           'zope.schema',
                           ],

where the 'extras_require' is to make the dependency on zope.testing 
only for the test runner installation (referred to in 'eggs' in the 
[test] section in buildout.cfg).

Grok currently doesn't list its dependencies properly and even if we did 
we'd pull in a huge part of Zope 3 (out of necessity). It would be nice 
if I could just list grok in 'install_requires' of my package and have 
everything working because Grok lists *its* dependencies again.

Doing this will allow us to put packages on svn.zope.org that use Grok 
as a dependency. These packages should be compatible so that they can be 
installed in a plain Zope 3 system. This is actually what I want to do, 
but then I ran into some obstacles.

How do we accomplish this? One thing to do is to simply start listing 
the dependencies in Grok's setup.py. But we also need to carefully 
examine which dependencies Grok pulls in and try to minimize them as 
much as possible (the ZMI..).

Then there are issues. Grok messes with Zope 3 security. We obviously 
don't want people's security to be magically turned off if they install 
a dependency that uses Grok.

To remedy both the 'vast number of dependencies' issue as well as the 
'Grok messes with my Zope' issue we could consider splitting Grok up 
into multiple packages. We could for instance have a grokcore.component 
that only defines Grokkers that use the pure component architecture, 
such as adapter grokkers. This would allow those packages that only need 
such Grokkers to only rely on this. We then have a Grok package that 
depends on all grokcore packages that imports everything into the 'grok' 
namespace package and adds Grok specific stuff like meddling with 
security. Doing this will reduce the level of buy-in for people to use 
Grok, and greatly enhances compatibility of Zope 3 and Grok. Someone can 
use a package with interesting functionalities that uses 
grokcore.component so that adapters are grokked instead of registered 
with ZCML, and they might not even be aware of it until they examine the 
code.

Finally we have the problem of when to start on this project. If we 
start now, we make Grok dependent on an eggified version of Zope 3. 
While I'm sure we want to do this soon, we don't want to break 
everything now. This means this work will likely need to be done on a 
branch for now. We shouldn't wait too long to start with this, as I 
think Grok has much to gain from an eggified Zope 3 universe, and the 
eggified Zope 3 universe from Grok.

Thoughts?

Regards,

Martijn