[Zope-dev] Stripping down zope.component

[Tres Seaver]

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

Martijn Faassen wrote:
> Hi there,
> 
> Tres Seaver wrote:
> [snip]
>> Actually, we don't need an upgrade path.  We can just leave a
>> 'meta.zcml' in zope.component which <includes> the new locations.  That
>> file will be *inert*, and doesn't therefore need testing, because none
>> of the directive implementations will be present.
>>
>> Over time, people can shift to including the new meta.zcml at their
>> leisure.  We can leave the redirecting meta.zcml in zope.component
>> *forever*, if need be.
> 
> It's not just the meta.zcml story, where I can agree we could leave 
> something in place, but it's the dependencies in setup.py, right?

Right.  Dropping any dependency on zope.configuration, zope.security
etc. *will* happen.  The folks affected by such a change will be those
who rely on the current transitive dependency graph to pull in those
pacakges:  they will need to update their versions.cfg / setup.py, etc.
in order to pick up the new version of zope.component.  See below for
the documentation required.

> If the implementation of the directives lives in zope.componentzcml, any 
> codebase that loads any ZCML at all (in its tests especially) is very 
> likely to need zope.componentzcml besides zope.component. Or am I 
> missing something here?

It needs to have it importable, yes (so that the redirected meta.zcml
works).  Come to think of it, we could even leave the extras in place
for BBB, since anybody who has been relying on the transitive graph has
to be depending on 'zope.component[zcml]' already, right?  I don't have
a problem with leaving it in place as a pure dependecy shim.

> [snip]
>>> Anyway, this upgrade path needs to be spelled out clearly in the 
>>> zope.component CHANGES.txt pointing people in the right direction. We 
>>> also need to spell it out in this document:
>>>
>>> http://svn.zope.org/zope3docs/source/migration/34to35.rst
>> Maintaining that document is out of scope for me. ;)
> 
> If my above story about the dependencies is right, it is necessary to 
> remark this in a central place. We do have framework-wide policies in 
> place, and explaining to people how to unbreak their code in a single 
> place they can look should be one of them. We do after all have people 
> who use a whole bunch of these libraries at the same time. But if you 
> can write it clearly in the CHANGES.txt and tell me, I'll add it to that 
> document if you can't be bothered.

It isn't that I can't be bothered:  I'm don't want to reinforce the idea
of a new monolithic release labeled "3.5" to which people will upgrade
from the current "3.4" in lockstep.  Not only do I not want to *use*
such a monolith;  I'm convinced that trying to maintain it can impede
(and has impeded) develpoment of the actual bits which make it up.  I
won't do anything active to defeat your efforts in that direction, but I
don't want to help on that part.

In any package where I create a backward incompatibility, I will
certainly document it clearly, with instructions on how to update
dependent packages.  Putting the canonical docs in the package is an
absolute necessity for reuse of the package outside any larger package
set, anyway.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJsUeQ+gerLs4ltQ4RAihbAJ4gwRemxOz7/CT/wQUpkLEd++EQFgCfUHm6
0i2xCkbvckMB/pp59ezpCKk=
=n7Fv
-----END PGP SIGNATURE-----