[Grok-dev] the notion of "next Grok"

Martijn Faassen faassen at startifact.com
Wed Apr 15 11:07:49 EDT 2009


Hi there,

[this is a modified version of a post I made to zope-dev a few days ago. 
I got no real feedback there, so I'm trying here to see whether we can 
get this solved just for Grok]

During the post-Pycon sprint Hanno made me aware of a tool called
mr.developer. This tool allows you to easily turn a particular package
in your buildout into one you want to hack on, without you having to
know where to check it out from.

mr.developer has a concept of "next" (Plone-next). Given a release of
Plone, it needs to find out where the packages live in a version control
system, and whether the next version is the trunk or a branch.

During the Grok sprint in late january when z3c.recipe.compattest was
developed we ran into the same issue. We want to run compattests against
some released set of versions, but also against all development
versions. We took a shortcut there and just "guess" that all packages in
the Zope Framework live on svn.zope.org and are the trunks. This is
hardly ideal.

During the Pycon sprint Hanno also worked on a buildout recipe to draw
dependency graphs: z3c.recipe.depgraph. We want to be able to draw the
dependency graph of a selected set of versions, but we also want to be
able to draw the dependency graph of all development versions.

So we have three tools that need this concept. Grok needs those three 
tools too. This implies to me we need to expand the notion of Grok's
versions.cfg.

Currently our versions.cfg has two fields:

[pypi package name] [version]

If we are to expand this with a "next" notion, it would become like this:

[pypi package name] [version] [svn URL]

The svn url contains full information about where to check out the next
version of the package. If we want to support alternate version control
systems, we'd need to expand that, though I hope that all alternate
version control systems have a notion of a URL to point to a version.

Once we have this extra information, we can publish it.We can't put the 
SVN URL in our versions.cfg. But we could also  export another file per 
Grok release that contained the package name and the SVN URL. I believe 
mr.developer takes that kind of information. Once we have that, we can 
then adjust our tools to make use of this extra information.

Opinions? People who want to implement this? We'd need to modify Grok's 
development and release procedure so we maintain this list of "next" 
versions as well, though typically this is just a list of trunks.

Once we got it working for Grok we might want to push this down into the 
Zope Toolkit, but I think Grok will have to pick up the ball here for 
now, make it work for Grok. We can approach Plone developers on this 
list too (or directly). I got nobody interested in this topic over on 
zope-dev...

Regards,

Martijn



More information about the Grok-dev mailing list