[Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]

[Tres Seaver]

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

Martijn Faassen wrote:
>   Hi there,
> 
> Tres, please tell me what I should be doing as opposed to moving
> things around and deprecating them.
> 
> I want a version of Grok with far less dependencies than it pulls in
> now. I believe there are a lot of advantages in doing that, and I'm
> not going to go into them here as I'm sure you can imagine them
> yourself.
> 
> There are two ways I can go about that:
> 
> a) break everybody's APIs and rewrite parts of Zope 3 itself so we
> have less dependencies for Grok.
> 
> b) refactor Zope 3 itself so that there are less spurious dependencies
> that get pulled in.
> 
> You're complaining that b) is going to cause people trouble as they
> see deprecation warnings. Fine, we can evolve towards a system to do
> deprecation warnings better.
> 
> But you also seem to be suggesting we shouldn't even do b) in the first 
> place.

Doing b) is fine.  What I am objecting to is the part where we (plan to)
break imports of symbols from their old locations, instead of just
leaving them importable from that place *forever*.  Note that we would
*not* be adding deprecation warnings in the old location if the code
there (where the symbols used to live) actually used the
now-refactored-to-another module symbols.

> a) is a much greater break with the past than b), however. What is the
> alternative that I'm missing? Or are you suggesting we break
> everybody's code and go for a)? Why then arguing a smaller refactoring
> that tries hard to keep things working? (I expect the Grok project
> will involve a combination of a) and b) in the end, but hopefully as
> little a) as possible).
> 
> It's not a theoretical cleanliness we're talking about here.
> 
> zope.app.form is *not* a dependency of z3c.form anymore, and I
> consider this a win for z3c.form. Less code installed, and people who
> wade through the code won't run into the very misleading zope.app.form
> anymore.

I consider that a win, too.  What I'm objecting to is the idea that we
release a new version of *zope.app.form* which breaks imports of the
symbols which used to live there.  Instead, I'm arguing that we leave
the BBB imports of that symbol in the old location, forever.  Note that
the new zope.app.form depends already on the new location of those
symbols, so we aren't adding any cruft beyond a single line per symbol,
along the lines of the following (I think it would be in
zope.app.form.interfaces)::

 from zope.browser.interfaces import ITerm # BBB

> I've also noticed a similar win with z3c.saconfig. I forget
> the details, but I was very careful not to pull in a certain
> dependency as that pulled in all of Zope 3, and I wanted to keep
> dependencies under control. Then someone added a feature that needed
> that dependency. Then it turned out that in the mean time a new
> version of the dependency had been released that *didn't* pull all of
> Zope 3. That made me happy, as it strikes to me that a lot of small 
> improvements like that may significantly reduce the set of dependencies 
> many Zope 3 installations require.

I'm in favor of reducing dependencies, and actively in favor of the
refactoring which breaks apart the "dependable" bits (e.g., into the new
zope.browser package) from the others.  I just don't want to emit
deprecation warnings now, or ImportErrors later, for imports from the
old location.


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

iD8DBQFJTyER+gerLs4ltQ4RAlmIAJ9SXtb8G00l9SXrxhpLFTFPEg1bOwCeLuVj
+Xl2O6vkZsrLMEt4ScFgwOI=
=wo9Y
-----END PGP SIGNATURE-----