Thomas Lotze wrote: [snip]
- make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL
I agree we should make it available under a versioned URL somehow. Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that. The reason I mentioned docs.zope.org as the release location is because we will also publish release-specific ZTK documentation when we make a release. The release-specific documentation should be maintained and tagged along with the ZTK itself, and we should have easy access to previous versions of the docs on versioned URLs. But it's true "docs.zope.org" isn't a very pretty URL for this. Perhaps we should have: http://ztk.zope.org/ This will contain the general intro about the ZTK and the version-independent management information we currently host at http://docs.zope.org/zopetoolkit/ There is also a release overview page, and this gives a list of the ZTK releases. There's also a link to the 'current' release: http://ztk.zope.org/release/current/ which in turn redirects to (or *is*?) the most recent version of the ZTK, for instance: http://ztk.zope.org/release/1.0 The release contains release-specific documentation, including a package list like this: http://docs.zope.org/zopetoolkit/releases/packages-trunk.html It also can contain the dependency graphs for that release, and any other release-specific documentations. (overview of changelogs for all packages?) Finally, and most importantly, it publishes the ztk.cfg for the release. As Hanno suggested, we can also host an index there. The structure might look like: http://ztk.zope.org/release/1.0/ztk.cfg and for the index: http;//ztk.zope.org/release/1.0/index/ I think it makes sense to separate the two and not have the ztk.cfg inside the index. You typically use either the index or the ztk.cfg file independently from each other, I think. As a side discussion: I'm not entirely sure what benefit the index is to the Zope 2 project however; doesn't using a custom index like this stop the project from using any other release on PyPI? I know that Zope 3 has a special index that only locks down Zope 3 dependencies and defers to PyPI for the rest, but that doesn't sound ideal either. A pattern I've seen Tres advocate is of using a custom index per project containing exactly those packages the project needs - how much help would a ZTK index be to support that use case? Regards, Martijn