[Zope-dev] Zope Toolkit - packages with zope.app dependencies

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hanno Schlichting wrote:
>> On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen
>> <faassen at startifact.com> wrote:
>>> Hanno Schlichting wrote:
>>>> The ZTK no longer contains any zope.app packages.
>>> I think we should be careful to just remove the zope.app packages from
>>> the ZTK entirely. I.e. we should maintain the versions of the zope.app.*
>>> packages that were in Zope 3.4 (or at least the original Zope 3 tree) in
>>> the ZTK for the time being. Otherwise we make people's life rather
>>> difficult.
>> I disagree. In my opinion it's not part of the job of the ZTK to
>> provide backwards compatibility with Zope 3. The toolkit is not a
>> replacement for all of Zope 3 and you cannot run a Zope 3 application
>> even after following all the refactorings on the toolkit alone. If
>> users of Zope 3 want an upgrade story, they need to get together and
>> make a new Zope 3 release which is based on the ZTK.
> 
> Totally ignoring our community's responsibility towards backwards 
> compatibility and delegating it to a mythical set of "Zope 3 
> maintainers" isn't an option at all.

The reality is that the zope.app.* packages don't fit the mission of the
ZTK:  they aren't widely-reusable libraries, but pieces of a particular
appserver / framework.  The other reality is that nobody is stepping up
to do the work to maintain that appserver.

There is *not* BBB issue with dropping those packagse from the ZTK,
because everybody who is currently deployed with them has a valid way to
use them *without* the ZTK.  Pushing the burden of maintenance of those
packages onto the ZTK, instaead of onto the portions of the community
who use them, reduces the viability of the ZTK for almost no gain.

> We need to provide an upgrade path from pre-ZTK applications to ZTK 
> applications. This upgrade path can take the form of a set of versions 
> of zope.app.* libraries that people can choose to install for backwards 
> compatibility. We should maintain this set of versions as part of the 
> ZTK's test regime at the very least, otherwise we'll inevitably break 
> something.

Toolkits aren't frameworks or appservers:  migration paths aren't part
of their story:  if you need a tool which doesn't come with the toolkit,
you purchase it seaparately.  If the tool *used* to come with the
toolkit, and you still need it, you pull it out of the old toolkit and
keep it on the side when you replace the toolkit.

Defining those upgrade paths is the responsibility of the various groups
consuming the (new) ZTK:  in the case of Zope2, the Zope2 maintainers
have chosen to do the work to remove all dependencies on zope.app.*
packages from Zope2, leaving Zope2 free to use a zope-app-free ZTK
without any issues.

>> For Zope2 we have covered the upgrade story already. Zope 2.12 uses
>> its own KGS, which includes the entire set of zope.app packages in
>> compatible versions. 
> 
> Let's please please please maintain that set of zope.app.* packages 
> centrally. Zope 2 isn't the only consumer of these packages.

What set?  Why do you think that any given set of them is worth
maintaining?  Grok uses some subset of them, while a Zope3 app uses a
bigger set, but Zope2 uses none:  why is Grok's set (or Zope3's)
important enough for the wider group of ZTK developers to care about?

>> On a more practical note, it's actually just not helpful to include
>> version pins for any zope.app packages in the ztk.cfg. I can add any
>> arbitrary set of version definitions there. Then run the test-ztk
>> tests and all tests will always pass. Since the packages under tests
>> don't include nor depend on any zope.app packages, their test result
>> is independent of any zope.app version pins.
> 
> Then we certainly need to do more than version pins. We also need to 
> test these packages.
> 
> -1 to this change. I'm going to add the zope.app.* packages back to the 
> ZTK until we've had a proper discussion about how, as a Zope community, 
> we go forward with this. Delegating this responsibility *separately* to 
> sub projects is just plain silly.

You are treading on very dangerous ground here:  commit wars are not a
good way to solve this problem.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks6cZcACgkQ+gerLs4ltQ79/gCgxBltITz0Rn9DEZxvwK2EleLQ
np0An3vNmFWWGE2/OzSOLL+zTWA/mvrt
=LFUf
-----END PGP SIGNATURE-----