It already happened last week, but I thought I'd mention our Grok 0.14
release. Grok 0.14 is the first release of Grok that officially works
with Python 2.5, though unofficially Grok has worked with Python 2.5
for a while on many platforms. There is already a report of Grok working
with Python 2.6! The other major change in this release is the spin-off of three new
libraries that are also reusable in plain Zope 3 applications as well
as in Zope 2 (through five.grok): We've also spun off the grokui.admin package. This contains Grok's
user interface. This should means it becomes possible to deploy Grok
applications without this user interface included, which adds security
to deployments. Earlier already Grok has spun off grokcore.component, which is a
layer on top of zope.component and zope.configuration enabling
you to use Zope's component architecture while writing plain Python
code. Earlier still, the Grok project spun off the martian library for
deducing configuration from Python code itself. Martian has much
improved since its first release, making it easier than ever to
auto-register classes with any configuration system of your choosing,
define directives and declare sensible defaults in case those
directives are not used. Why do we spin all these packages off? Why not develop Grok as one big
lump of code? The reality is that we can't anyway - Grok is based on a
whole range of Zope 3 components and other packages that are developed
separately. Why though do we make our lives harder and split off things
from Grok itself? First, thanks to buildout our lives are not that much more
difficult. It's easy enough for us to continue to develop these
packages in synch with each other when we want to. We can use svn
externals to pull a development version of a package into another and
then tell buildout we want develop using that version. This is
basically an enhanced version of setuptools develop installation
mode. Still, why is it worth it? In the abstract, splitting off separate packages helps us safeguard
conceptual integrity of a package. Giving a package a separate
identity makes us think about what this package is really for, and
helps keep the scope of a package clear. Since we use separate packages with separate reponsibilities, it
allows us a smoother framework evolution as well - we can more easily
decide to drop a feature from the core and adopt another feature into
the core if these features are independently packaged. Most importantly and most concretely, the separate packaging helps
with code reusability. The Grok developers want the Grok technologies
to be used by many people. We've already seen the uptake of our
grokcore.* packages in plain Zope 3 projects by developers who like
some of Grok's features but don't want to pull in all of Grok. Even
more importantly Zope 2 developers are starting to use our technology
in CMS projects such as Silva and Plone. The martian package has
also seen use in projects like repoze.bfg. This way a wider
community becomes a stakeholder in the Grok project, and we feel this
is very important. How easy is it to use our code in non-Zope Python projects? The answer
varies. Martian has only a dependency on
zope.interface. grokcore.component has a slightly larger but
still very well defined set of dependencies and is still entirely
reusable in any Python project. The other packages unfortunately are
dependent on a larger set of Zope 3 dependencies making them not
reusable outside of a Zope setting. The Repoze project has made many Zope technologies available to the
outside world. The Grok project is looking at starting to use some of
that code. The Zope developers are also looking at the Zope packages
themselves to see whether we can't cut some more dependencies here and
there increasing their reusability. That's another advantage of
separate packages: it makes us aware of reusability issues, and lets
us work on it.
![[Comments]](/blog-content//themes/Default/comments.png "3 comments")
(3) Tue Oct 07 2008 15:16 Grok's release mill:
- Comments:
Posted by Tom Hoffman at Tue Oct 07 2008 18:41
SchoolTool certainly appreciates your efforts to make Grok code reusable!
Posted by Robert at Tue Oct 07 2008 23:26
Bless you for getting 2.5 support in "officially".
Posted by Robert at Thu Oct 09 2008 23:01
Snap! It isn't working on Leopard. I did everything according to the setup docs.
