+- Make ``class`` directive schemas importable from old location, + raising a deprecation warning. It was moved in the previous release, + but some custom directives could possibly use its schemas.
Out of curiosity, *was* it used by custom directives that you know of?
Well, I personally found out that they were removed while checking out the z3ext packages. Some of them use "require" and "allow" subdirectives for their custom directives. In the case of "allow" and "require" it's quite easy to think out the case where they will be reused.
A more philosophical question: are the interfaces used to implement a directive part of a public API that is reusable or not? When we moved the directive implementation I arbitrary made the assumption that it'd be fine to just move them wholesale, but you clearly don't agree. Besides the interfaces, should the implementation also have backwards compatibility imports? I guess sometimes reuse by interface subclassing does happen in directive implementation, but of course we could declare that such reuse is only intra-package.
It looks like "yes, it should" to me. AFAIK, we reuse directives in zope itself and in other packages. One example is z3c.pagelet that reuses IBasicViewInformation schema and functions like "handle_permission" or "handle_for". However, that might be considered as a flaw to be fixed, so there's a place for discussion on that topic. However, I think that it's even good for directives to be a part of reusable API. What if we want to create an extended <browser:page /> directive, adding only one custom field? The implementation functions and classes are also reused sometimes. We reuse the zope.component's directives like "adapter" and "utility", so why not reuse a ClassDirective if it fits our needs?
In my mind, it's also less risky to move a directive implementation even if it is reused, as the amount of external reuse is likely rare and is less likely to be in end-user code. The developers of the code layered on top of the directive definition would therefore be quite capable of fixing any breakage quickly.
Of course, its clearly okay to move directive schemas and definitions around, but I believe, that we need to support old imports for one or two "big releases" as we did before. There's a nice deprecation framework, provided by zope.deprecation and zope.deferredimport, so why not just use them to maintain backward compatibility while signaling people that they need to update their code? Not everyone is so quick and has time to fix the breakage. It's also quite hard to qucikly find where did the thing move if there's no compatibility imports or comments w/o reading changelogs.
But of course placing a few imports for backwards compatibility is not a lot of work and may be the easiest way out of this set of questions. :)
Yep. Also, as I said before I think we also need to use deprecation warnings for imports that are not classes for persistent objects (until Chiristian writes the tool to upgrade them :)). -- WBR, Dan Korostelev