Hey, On 10/24/07, Tres Seaver <[EMAIL PROTECTED]> 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 _______________________________________________ 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 )
