Hey, On 10/24/07, Tres Seaver <tseaver@palladion.com> wrote:
Martijn Faassen wrote: [snip]
Take a library that registers views (multi adapters) as widgets for form fields, for instance. Do you consider this to be an application-like library? I consider this to be a library.
I can see that. I still don't want its view registrations automagically included in my configuration. If it exposes an entry point signalling that it is a plugin for the specific application I'm running, that would be different.
I propose below to classify these entry points not by application but by type. You'll almost have to otherwise you'll end up touching quite a few libraries for each framework or pluggable application that gets written, right?
The 'pkg_resources.require' function lets you spell your dependency before you import; you'd still have to import whatever names you wanted from the distribution, but you could be naming both in the same module.
Right, I did read what you pointed out elsewhere in this discussion. Thanks for pointing that out. It bears some investigation. I am wondering whether we can make some buildout recipe that, together with a database of what distributions provide which imports, can determine what to fetch and bake it into the setup.py of the package under development. Together with a 'known good versions' system it could even fetch a reasonable version.
Again, I see your points. I think it makes sense for libraries to be light on policy. It's also clear that for instance ZMI views are too much policy one gets with a typical Zope 3 library. I don't think we should however consider all libraries that register a few adapters as 'policy heavy'. Once we take the ZMI registrations out, is what is left policy-heavy or policy-light?
I don't want to have to override *any* policy imposed by a library, unless I specifically choose to enable that policy in the first place.
Sure, but one person's policy is another person's behavior. :) I disagree with the position that should not ever treat an adapter registration as an implementation detail to provide some default behavior. Sometimes the behavior of a library *relies* on certain adapters being registered. An example is an adapter registration to generate an appropriate error message (if no more specific adapters are registered by the user of the library). Anyway, I think we're mostly going round and round. Currently we're debating what the entry point means that says "load the basic ZCML". So perhaps we need a "minimum ZCML" and "convenient defaults ZCML" entry point, which may be one and the same in some cases. A framework can then choose to load convenient defaults by default, or absolute minimum stuff by default. To get started we should pick one entry point - if someone finds it loads too much policy we can add another one, or if someone finds it loads too little, likewise. Regards, Martijn