Thomas Lotze wrote:
> - make ztk.cfg available from (why, 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 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 "" 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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to