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
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. This implies to me we
need to expand the notion of KGS. (where I take it in the broad sense
where we are talking about a known good set of something; Zope 2, Zope
3, Zope Framework, Grok, etc).
The abstract notion of KGS currently is has these two fields (per
package part of the KGS):
[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. Currently KGS
exports the known versions list as a buildout versions section
compatible list. We can't put the SVN URL in there. But we could also
export another file per KGS 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
Opinions? People who want to implement this?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -