Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
snip platform / KGS stuff
For the case of *library* packges, rather than platforms, forcing users
into lockstep on dependencies is less desirable.
Example
-
Assume that developer Fred releases a given library distribution,
'foo-1.2.tar.gz', with the following dependency in its setup.py::
install_requires=['bar = 0.9']
And inside the 'foo' package, some module does the following import::
from bar.baz import someAPI
At the time this version of foo is released, the following versions of
'bar' are available from Barney's website:
bar-0.9.tar.gz
bar 1.0.tar.gz
bar-1.0.1.tar.gz
None of those 'bar' versions have a deprecation for the import above,
and so code which uses the 'foo' package emits no warnings.
At some point, Barney decides to refactor the 'bar' package, and moves
'someAPI' from the 'baz' module to a new 'qux' module. If nothing else
in 'baz' *uses* 'someAPI', Barney has two choices:
- - Import the symbol for BBB, and leave it forever::
from bar.qux import someAPI # BBB
- - Import it for BBB, but mark it deprecated::
import zope.deprecation # note new dependency!
zope.deprecation.deprecated('someAPI',
'Usually a multi-line explanation here')
from bar.qux import soemAPI # BBB
The issue is moot if the 'baz' module actually uses the moved symbol.
Nobody actually puts deprecation warnings around non-BBB imports created
during refactorings if the module doing the import actually uses the symbol.
Note that Barney is *adding* cruft to 'baz' (the several lines of stuff
to this module to spell the deprection), and that he has created a
future maintenance burden (ripping out the import / deprecation at some
point in the future).
Then look what happens to Wilma's application which uses 'foo', and
transitively depend on 'bar': once she updates to bar 1.1 (e.g., to
pick up an unrelated bugfix), her application begins to emit warning
messages, even though the application doesn't use the deprecated symbol
directly. Either Wilma must live with the warning, or else she leans on
Fred to release a new version of 'foo'.
Note that the relased version of 'foo' continues to *work* with baz =
1.1 (at least until the eventual removal). Assume that 'foo' is
hyper-stable, and would otherwise not need to be updated at all; Fred
is now in the position of being pressured to make a gratuitous release
in order mollify Wilma.
If Fred *does* want to accomodate the complaints from the application
author, he then has to make choices:
- - Support both locations via a conditional import (AKA add cruft)::
try:
from baz.qux import someAPI
except ImportError:
from baz.bam import someAPI
- - Drop support for the older location, and update the 'install_requires'
accordingly. Now, users who pick up the new 'foo' version will be
forced to upgrade 'bar', even if they would otherwise not want the
new version.
Most of my components work with a wide version range of other
components. I would not like to expose a single version.
Usually, I include a narrative of the form: known to work with 2.6.x
through 2.11.x; may work with other versions as well (not tested).
What will you do once Zope 2 is split up into multiple packages? How
would you express such a thing about Zope 3 if there is no canonical
list of versions (such as KGS)? Grok is in the position of Zope 2 or
Zope 3 here.
Of course we prefer the individual components that Grok is composed
of, and extensions to Grok, to work with multiple versions of Grok.
That's unrelated to the need to actually *have* versions of Grok in
the first place. It's desirable to have each component work with a
range of versions of other components. It's also desirable to make a
collection of components work out of the box with a well-known set of
versions that can be communicated about, because this selection itself
has a version number as well.
In the past, I have seen excessive deprecation warnings and had
the feeling that the warning feature is overused (as many new features).
I think it's clear that many people do not like seeing deprecation
warnings during startup and runtime and that it's been quite a burden
on developers. I can see how it is frustrating to developers (one or
multiple steps away)/
It's also clear to me that if we want Zope 3 to move forward, we need
a much less convoluted dependency structure and have the ability to do
some relatively bold refactoring. We will therefore need to move
things around a lot more, and I fully intend to make progress on that,
and join Roger in his work.
I therefore propose we make a new kind of deprecation system that uses
the same system to mark up source code as we have now, but does never
emit the warnings during run-time. Instead we create an external
scanning tool that can report about deprecated imports in a package
(and perhaps help fix them automatically).
I
[Zope-dev] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Fri Dec 19 12:00:00 2008 UTC to Sat Dec 20 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 19 20:35:50 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010685.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Fri Dec 19 20:37:20 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010686.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Fri Dec 19 20:29:49 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010681.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 19 20:31:19 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010682.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 19 20:32:50 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010683.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 19 20:34:20 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010684.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] If we that there is a real goal other than future cleanliness for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. I think it's more then future cleanliness. My goal is to reuse as much as we can. This means, if we deprecate zope.app.form.browser.interface.ITerms. And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. Reegards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] If we that there is a real goal other than future cleanliness for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. I think it's more then future cleanliness. My goal is to reuse as much as we can. This means, if we deprecate zope.app.form.browser.interface.ITerms. And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. You lose the reusability of any existing packages which supply the old interface / location once you finally remove the interface from the deprecated location. Unless their maintainers issue new versions of their packages (as Fred did in my example, to keep from sleeping outside with Dino in ;), your code will not be able to use both the new version of the framework *and* the old plugin at the same time. Refactor mercilessly is a mantra of a methodology which is specifically focused on building applications, rather tha libraries / frameworks. Once you have downstream users who are not actively involved in the development of your package, the costs of refactoring go up. As an example from outside Zope land: Linux developers fiercely defend their practice that there is no stable ABI in the kernel; out-of-tree modules have to be recompiled to be compatible with new kernel versions, including refactorings, etc. However, they are equally fierce in the policy that a user-space API, once released, is maintained *forever*. User-space code which uses such an API *must* continue to work. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJTYlG+gerLs4ltQ4RAqd7AKCpf4om3G6gpx0ilfiw1/83JgoxUgCgjBBP GBHZ4dF3Ts2UmVWKEZD5+IE= =RCah -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
