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