[Grok-dev] grok in the egg universe
faassen at startifact.com
Sat Apr 14 11:48:59 EDT 2007
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:
Its buildout.cfg is just:
develop = .
parts = 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',
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
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.
More information about the Grok-dev