Mailing List Archive: Zope: Dev

Updating the ZTK KGS

Index | Next | Previous | View Threaded

tl at gocept

Sep 30, 2009, 11:07 PM

Post #1 of 9 (993 views)
Permalink

Updating the ZTK KGS

Having worked on and released new versions of a few ZTK packages recently,
I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
there doesn't seem to be an agreed process about this and in an attempt
not to step on anyone's toes, I'd like to ask first whether it is OK for
any developer to modify the versions listed in ztk.cfg (provided that all
relevant tests are passing, of course). I'd currently like to update the
following packages:

zope.app.apidoc = 3.6.7
zope.app.publication = 3.9.0
zope.error = 3.7.0
zope.location = 3.7.0
zope.site = 3.7.0
zope.traversing = 3.8.0

--
Thomas

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Oct 5, 2009, 5:22 AM

Post #2 of 9 (906 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

Thomas Lotze wrote:
> Having worked on and released new versions of a few ZTK packages recently,
> I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
> there doesn't seem to be an agreed process about this and in an attempt
> not to step on anyone's toes, I'd like to ask first whether it is OK for
> any developer to modify the versions listed in ztk.cfg (provided that all
> relevant tests are passing, of course). I'd currently like to update the
> following packages:
>
> zope.app.apidoc = 3.6.7
> zope.app.publication = 3.9.0
> zope.error = 3.7.0
> zope.location = 3.7.0
> zope.site = 3.7.0
> zope.traversing = 3.8.0

Thanks for bringing this up.

There's indeed currently no agreed-upon process. Jim a while ago was
proposing a rather heavy staging process where the trunk can only be
changed if a staged branch passed all tests on all platforms (and Python
versions) as run by a buildbot. We don't have the infrastructure for
this yet and Christian Theune and I were wondering whether this is needed.

An alternative process would be to only *release* the ZTK after the
compat tests run on all platforms as shown by the buildbot. We do have
infrastructure for that.

So I'd propose the following development process:

* developers can change the version numbers in the ZTK

* if the compattests all run, they can check in

And then for releases:

* we determine we want to make a release of the ZTK

* if the buildbot reports it all works on all platforms

* we verify there have been no further modifications since then

* we can release

* what does a release look like exactly? We should at least have a
documentation release sitting somewhere on docs.zope.org, with the
release number in the URL. The 'current' URL should also point to this
documentation. Along with this we should also publish the lists of
versions for reuse. How?

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

tl at gocept

Oct 5, 2009, 7:44 AM

Post #3 of 9 (910 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

Martijn Faassen wrote:

> So I'd propose the following development process:
>
> * developers can change the version numbers in the ZTK
>
> * if the compattests all run, they can check in

I'll go ahead and update the KGS with my proposed new versions then; if
someone experiences a problem with this, feel free to flame me ;o)

> * what does a release look like exactly? We should at least have a
> documentation release sitting somewhere on docs.zope.org, with the release
> number in the URL. The 'current' URL should also point to this
> documentation. Along with this we should also publish the lists of
> versions for reuse. How?

I see two options:

- make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a
versioned URL

- release a ztk egg that depends on the exactly versioned packages

The latter is probably the more reusable.

--
Thomas

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

hanno at hannosch

Oct 5, 2009, 8:00 AM

Post #4 of 9 (913 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

On Mon, Oct 5, 2009 at 4:44 PM, Thomas Lotze <tl [at] gocept> wrote:
> I see two options:
>
> - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a
> versioned URL
>
> - release a ztk egg that depends on the exactly versioned packages
>
> The latter is probably the more reusable.

I'd suggest to follow the Zope2 approach and provide both an index and
a versions.cfg at a permanent place. The result looks like this:
http://download.zope.org/Zope2/index/2.12.0/

You can use this with both easy_install and buildout easily. Andreas
wrote a very simple script that is able to produce such a minimal
listing.

I don't see how a ZTK meta-egg would be of any value. Given that the
number of packages included in the ZTK will change quite a bit over
time, it doesn't make sense to depend on a ZTK egg for a package, as
it doesn't provide any real stable contract. An egg with hard coded
exact version numbers is pretty painful as well, as you cannot
override those requirements to go for selected newer versions of any
packages pinned in such a way. Opting for a newer zope.testing release
for example is quite a common requirement.

I don't think it makes sense for anyone to "install the entire ZTK".
Projects being built on top of the ZTK are most often only interested
in a part of the ZTK and will depend on such packages explicitly. What
is valuable for those, is the stability contract between various
versions of packages in the ZTK.

Hanno
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

ct at gocept

Oct 6, 2009, 2:06 AM

Post #5 of 9 (901 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

On 10/05/2009 02:22 PM, Martijn Faassen wrote:
> Thomas Lotze wrote:
>> Having worked on and released new versions of a few ZTK packages recently,
>> I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
>> there doesn't seem to be an agreed process about this and in an attempt
>> not to step on anyone's toes, I'd like to ask first whether it is OK for
>> any developer to modify the versions listed in ztk.cfg (provided that all
>> relevant tests are passing, of course). I'd currently like to update the
>> following packages:
>>
>> zope.app.apidoc = 3.6.7
>> zope.app.publication = 3.9.0
>> zope.error = 3.7.0
>> zope.location = 3.7.0
>> zope.site = 3.7.0
>> zope.traversing = 3.8.0
>
> Thanks for bringing this up.
>
> There's indeed currently no agreed-upon process. Jim a while ago was
> proposing a rather heavy staging process where the trunk can only be
> changed if a staged branch passed all tests on all platforms (and Python
> versions) as run by a buildbot. We don't have the infrastructure for
> this yet and Christian Theune and I were wondering whether this is needed.
>
> An alternative process would be to only *release* the ZTK after the
> compat tests run on all platforms as shown by the buildbot. We do have
> infrastructure for that.
>
> So I'd propose the following development process:
>
> * developers can change the version numbers in the ZTK
>
> * if the compattests all run, they can check in
>
> And then for releases:
>
> * we determine we want to make a release of the ZTK
>
> * if the buildbot reports it all works on all platforms
>
> * we verify there have been no further modifications since then
>
> * we can release
>
>
> * what does a release look like exactly? We should at least have a
> documentation release sitting somewhere on docs.zope.org, with the
> release number in the URL. The 'current' URL should also point to this
> documentation. Along with this we should also publish the lists of
> versions for reuse. How?

I would agree with that as a basis for getting started. I think during
the course of making the first pre-releases for the ZTK we'll be able to
spot issues with that and improve further.

Christian

--
Christian Theune � ct [at] gocept
gocept gmbh & co. kg � forsterstra�e 29 � 06112 halle (saale) � germany
http://gocept.com � tel +49 345 1229889 0 � fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Oct 6, 2009, 10:02 AM

Post #6 of 9 (899 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

Hey,

Hanno Schlichting wrote:
[snip]
> I don't see how a ZTK meta-egg would be of any value. Given that the
> number of packages included in the ZTK will change quite a bit over
> time, it doesn't make sense to depend on a ZTK egg for a package, as
> it doesn't provide any real stable contract. An egg with hard coded
> exact version numbers is pretty painful as well, as you cannot
> override those requirements to go for selected newer versions of any
> packages pinned in such a way. Opting for a newer zope.testing release
> for example is quite a common requirement.
>
> I don't think it makes sense for anyone to "install the entire ZTK".
> Projects being built on top of the ZTK are most often only interested
> in a part of the ZTK and will depend on such packages explicitly. What
> is valuable for those, is the stability contract between various
> versions of packages in the ZTK.

I agree with this - I see little value in a ZTK egg, and I also agree
the ZTK explicitly supports using part of the ZTK only.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Oct 6, 2009, 10:14 AM

Post #7 of 9 (895 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

tl at gocept

Oct 6, 2009, 10:36 PM

Post #8 of 9 (893 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

Martijn Faassen wrote:

> 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.

I'd say it does; it contains a line

allow-picked-versions = false

which makes buildout complain if it ends up using a package whose version
it had to pick from the index, so you're required to specify a version for
every package used by any part of the buildout. This line is a piece of
policy that I'd like to see gone from ztk.cfg as well; if someone wants
the behaviour, they can specify it in their buildout.cfg.

> 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.

Agreed.

--
Thomas

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

faassen at startifact

Oct 7, 2009, 1:27 PM

Post #9 of 9 (888 views)
Permalink

Re: Updating the ZTK KGS [In reply to]

Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> 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.
>
> I'd say it does; it contains a line
>
> allow-picked-versions = false
>
> which makes buildout complain if it ends up using a package whose version
> it had to pick from the index, so you're required to specify a version for
> every package used by any part of the buildout. This line is a piece of
> policy that I'd like to see gone from ztk.cfg as well; if someone wants
> the behaviour, they can specify it in their buildout.cfg.

Agreed. We need to know why it's there first. I'll ask.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads