Hi there, 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. 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 information. Opinions? People who want to implement this? Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )