Re: [Repoze-dev] entry points vs ZCA registrations
On Mon, Nov 15, 2010 at 3:20 PM, Iain Duncan iainduncanli...@gmail.comwrote: thanks guys, Ethan that sounds like exactly what I'm looking for! Can anyone ooint me at good examples of the combination? Maybe not ;-) Plone has been using z3c.autoinclude since .. 3.3 iirc, but I don't know how many plugins are actually plugging themselves in this way. (Plone has historically had other mechanisms for add-ons to register themselves, which still work.) Anyway, Plone only defines a single extension point. The use case is just automating registration/configuration of add-ons for every package that's installed. In my application (zope/plone based) there's a slightly more complex use case. Like plone, we want to register application plugins that provide optional features through ZCA configuration, and we want them to be automatically enabled when the package is installed. Meanwhile, we also want to allow for overriding certain core components. Right now only one, the global site configuration utility, but I can imagine others too. (We want to allow the site configuration utility to be overridden because different kinds of configuration mechanisms -- a single INI file, multiple INI files, conceivably something persistent in the database -- would make the most sense depending on how the application is installed, and what features it's installed with.) But, application plugins may need access to the site configuration utility during their own registration. So we provide two extension points. One is for registration of regular optional features. The other is for registration of implementations of core components. In our core ZCA registrations, we find-and-register the latter early, and we find-and-register the former late. Packages declare which extension point they want to plug into. A single package could conceivably declare that it provides plugins for both extension points, but we haven't needed that.. I can point you to the code if this explanation isn't helpful .. there's a lot of context cruft so I don't think it would be self-explanatory though. -Ethan great input from this list as always. =) iain On Mon, Nov 15, 2010 at 7:34 AM, Ethan Jucovy ethan.juc...@gmail.comwrote: On Mon, Nov 15, 2010 at 4:59 AM, Wichert Akkerman wich...@wiggy.netwrote: On 11/14/10 05:32 , Shane Hathaway wrote: On 11/12/2010 03:17 PM, Iain Duncan wrote: Reading some of the diaolgue on the pylons/bfg merger has me curious about the following, wondering if any experts care to share opinions and war stories: - what is the best use case for extending through entry points? - why/when would you use entry points and entires in an ini file vs registering modules/plugins as zca entries? - pros and cons of each approach? With ZCA, you can register components temporarily for a test. You can create a short-lived component registry. You can create multiple registries for different parts of the application. You can store registries in a database. Whatever makes sense. With entry points, can you do any of that? Entry points seem far more limiting. Please correct me if I am wrong. Entry points work without you having to configure and python, zcml, etc. code, which makes them a better fit for some tasks. I think of the difference as -- ZCA is much more flexible and fine-grained as a component configuration system; entry points are good for lightweight tasks and for allowing a package to advertise the presence of a feature by virtue of the package being installed. To me, it makes sense to think of ZCA configuration as an integration layer attached to the application you're putting together, and entry points as attached to packages you might reuse (advertising features from the package you might want to make use of). You can also combine their use: in the z3c.autoinclude system, packages use entry points to advertise ZCML to be included. A package uses entry points to say I have ZCA configuration you might want, here and a ZCA configuration can say include all the ZCA configuration for key 'foo' from packages who offered it. Again, here, reusable packages advertise features (in this case groupings of ZCA configuration) and in the integration layer you put together a specific configuration. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
On 11/14/10 05:32 , Shane Hathaway wrote: On 11/12/2010 03:17 PM, Iain Duncan wrote: Reading some of the diaolgue on the pylons/bfg merger has me curious about the following, wondering if any experts care to share opinions and war stories: - what is the best use case for extending through entry points? - why/when would you use entry points and entires in an ini file vs registering modules/plugins as zca entries? - pros and cons of each approach? With ZCA, you can register components temporarily for a test. You can create a short-lived component registry. You can create multiple registries for different parts of the application. You can store registries in a database. Whatever makes sense. With entry points, can you do any of that? Entry points seem far more limiting. Please correct me if I am wrong. Entry points work without you having to configure and python, zcml, etc. code, which makes them a better fit for some tasks. Wichert. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
Iain- I'll offer my two cents. But first, I want to suggest the use of Extensions (http://pypi.python.org/pypi/extensions) opposed to setuptools style entrypoints. Distutils2, the successor to Distutils and therefore Setuptools, will not support entry points as part of the distribution setup. Or at least this was the decision the last time I looked. On 11/12/10 5:17 PM, Iain Duncan wrote: Reading some of the diaolgue on the pylons/bfg merger has me curious about the following, wondering if any experts care to share opinions and war stories: I have an actual case where I used used entry points in wsgioauth and I regret doing so. - what is the best use case for extending through entry points? Part of my decision to use entry points was from my experience at pycon. People hear reference to zope and either cringe or run away. So if people see zope.* as a dependency they decide not to use use it. ;) - why/when would you use entry points and entires in an ini file vs registering modules/plugins as zca entries? I'm a big fan of ini files, but they have limitations. Though, the simplicity makes this configuration format one of the best. Entry points are global. There need not be any direct reference to entry-point configuration like you would need to do in ZCA. So in the case of wsgioauth, I have wsgioauth.zodb which provides ZODB integration features. - pros and cons of each approach? The configuration is built into the distribution, rather than into say a zcml file or python configuration script. I consider this both a pro and con, because the defines are available right away and comes straight out of the distribution itself, but these are not definitions that can be easily changed. -Michael Mulich (pumazi) ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
On 15 November 2010 21:21, Michael Mulich mr...@psu.edu wrote: Part of my decision to use entry points was from my experience at pycon. People hear reference to zope and either cringe or run away. So if people see zope.* as a dependency they decide not to use use it. ;) I think this is one of those amazing self-perpetuating myths. If we all stopped saying this and thinking this, the issue would probably go away. Or at least go away in rational, constructive developers. I'm not sure Repoze/Pylons/Pyramid/Zope need care about those who are irrational or destructive. Martin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
On 11/15/2010 02:48 PM, Martin Aspeli wrote: On 15 November 2010 21:21, Michael Mulichmr...@psu.edu wrote: Part of my decision to use entry points was from my experience at pycon. People hear reference to zope and either cringe or run away. So if people see zope.* as a dependency they decide not to use use it. ;) I think this is one of those amazing self-perpetuating myths. If we all stopped saying this and thinking this, the issue would probably go away. Or at least go away in rational, constructive developers. I'm not sure Repoze/Pylons/Pyramid/Zope need care about those who are irrational or destructive. +1. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] entry points vs ZCA registrations
On 11/12/2010 03:17 PM, Iain Duncan wrote: Reading some of the diaolgue on the pylons/bfg merger has me curious about the following, wondering if any experts care to share opinions and war stories: - what is the best use case for extending through entry points? - why/when would you use entry points and entires in an ini file vs registering modules/plugins as zca entries? - pros and cons of each approach? With ZCA, you can register components temporarily for a test. You can create a short-lived component registry. You can create multiple registries for different parts of the application. You can store registries in a database. Whatever makes sense. With entry points, can you do any of that? Entry points seem far more limiting. Please correct me if I am wrong. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
