On Dec 20, 2008, at 2:12 PM, Chris McDonough wrote: > Paul Everitt wrote: >> >> On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote: >> >>> As a result of messing around with the ZCA + ZCML outside the >>> context >>> of Zope, >>> I've found that it may be possible to significantly reduce the >>> number >>> of egg >>> dependencies of BFG by replacing the code that allows the >>> following ZCML >>> directives to work: >>> >>> - utility >>> - adapter >>> - interface >>> - subscriber >>> >>> As such, I'm thinking of ditching the handlers written "zope" >>> namespace for >>> these directives in favor of handler written in the "bfg" namespace. >>> So, for >> >> Interesting idea. I suppose the decorator syntax wouldn't change, >> but >> the machinery behind it would. > > zope.configuration doesn't provide any decorator syntax, but if you > mean the
Sorry, I meant repoze.bfg.convention. I believe that, under the hood, it's doing the same configuration work as ZCML. > > ZCML syntax, yes, exactly; it wouldn't change for the "utility" or > "adapter" > directives. One "fallout" change would be that instead of: > > <bfg:view > for=".models.MyModel" > view=".views.my_view" > /> > > The view directive would be just: > > <view > for=".models.MyModel" > view=".views.my_view" > /> > > (because the "bfg" XML namespace would be the default). > >> >>> example, rather than doing: >>> >>> <configure xmlns="http://namespaces.zope.org/zope";> >>> >>> <utility >>> provides=".interfaces.IFoo" >>> factory=".foo.Foo"/> >>> >>> </configure> >>> >>> You would instead do: >>> >>> <configure xmlns="http://namespaces.repoze.org/bfg";> >>> >>> <utility >>> provides=".interfaces.IFoo" >>> factory=".foo.Foo"/> >>> >>> </configure> >>> >>> The down side of this is that it would mean that existing >>> applications >>> that used >>> ZCML would need to change their ZCML, or they'd at least need to >>> declare >>> "zope.security" as an install_requires dependency and do a manual >>> include of the >>> "zope.component" ZCML: >>> >>> <include package="zope.component" file="meta.zcml" /> >> >> I think it's pretty reasonable to make that requirement in order to >> get >> that gain. Meaning, apps would still work with a one-line setup.py >> change and a line of ZCML. > > Right. > >> >>> Creating parallel "adapter", "utility" and "subscriber" handlers is >>> really how I >>> should have started things out, but I didn't, and given that there >>> are >>> people >>> using the system in the wild that this would cause problems for in >>> a new >>> release, I wanted to ask for comments. >>> >>> Here are the dependencies we might be able to shed by doing this: >>> >>> zope.location-3.4.0-py2.4.egg >>> zope.publisher-3.5.4-py2.4.egg >>> zope.security-3.5.2-py2.4-macosx-10.5-i386.egg >>> zope.traversing-3.5.0a4-py2.4.egg >>> zope.i18n-3.6.0-py2.4.egg >>> pytz-2008i-py2.4.egg >>> >>> My personal opinion is that doing this is "worth it" for the long >>> term. None of >>> these packages actually *do* anything for bfg apps, they're just >>> required to >>> satisfy dependencies of features we can't use. >> >> For applications that do a Zope-ish architecture (ZODB, security, >> etc.), >> how many of those packages would they need to pull in manually? > > Security is not a feature provided by any Zope package in a BFG app; > ZODB > requires whatever its setup.py says it requires. > > In terms of the Zope-ish applications we (Agendaless) are developing > under BFG, > no changes would need to be made to any setup.py "install_requires". Right, I meant the latter. For people that are writing BFG applications that smell like Zope (e.g. KARL), how many of those packages would still be used, thus lessening the "win" in that case? --Paul _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
