Thomas Lotze wrote:
> - 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:
This will contain the general intro about the ZTK and the
version-independent management information we currently host at
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:
which in turn redirects to (or *is*?) the most recent version of the
ZTK, for instance:
The release contains release-specific documentation, including a package
list like this:
It also can contain the dependency graphs for that release, and any
other release-specific documentations. (overview of changelogs for all
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:
and for the 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?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -