If you have conditional imports scan doesn't work so well. I had this problem recently with a pyramid project where I didn't want a file imported otherwise it caused a syntax error. I think there are some good reasons why you don't use python as a configuration syntax. Another example is setuotools. You can't introspect metadata about a package without allowing full access to python. Its for this reason you can't run a query on pypi as to what package depends on what. If you want to remove XML from the syntax is python the best choice? On 6 Jan 2014 05:43, "Asko Soukka" <[email protected]> wrote:
> Hi Steve, > > thank you for your positive feedback. > > Do you think that the current syntax is ok as such, or would you like to > change something in it? > > To summarize the syntax: > > 0. packages should have [meta|configure|overrides].py similarly to zcml > (I'm not changing how zope.configuration works, but just adding a new > syntax for it from what we've learned from Grok and Pyramid.) > > 1. configure.namespaceshortcut.somedirective(*args) > > Any normal configuration call. (Namespaceshortcuts are simply > mapped into known namespace using a dict in c.venusianconfig.) > Classes, functions and methods (but not lambdas) can be passed > as arguments, but they are interpreted back to strings for > zope.configuration. > > 2. with configure(package='...') as subconfigure > subconfigure.namespaceshortcut.somedirective(*args) > > Nested directives are implemented with contextmanagers. > > 3. @configure.namespaceshortcut.directive.[class_|handler|etc](*args) > > Directive calls can be used as decorators by adding one more > part into configuration call (e.g. class_ for browser:page, > handler for subscriber, factory for adapter, etc.) > > 4. import submodule > scan(submodule) > > Decorators from other that [meta|configure|overrides].py must be > read with scan (similarly to Pyramid) > > Currently, scanning is not recursive and does even prohibit > scanning of subpackages in favor of configure.include(package="...") > > I'm still think thinking mainly two things before adopting this to our > team for internal packages: > > - scan() should probably be recursive and work for subpackages similarly > to Pyramid and Grok, but it would then compete with > <include package="" /> > > - should there be a set of predefined shortcuts like > > page = configure.browser.page > adapter = configure.adapter > > which could be used like directive > > or > > page_config = configure.browser.page.class_ > adapter_config = configure.adapter.factory > > which could be used as class/function decorator > > Shortcuts would make the configuration to look simpler, but would also add > "magic" and more difficult to mentally "map" the configuration code back to > zcml. > > Regards, > Asko > > Steve McMahon wrote: > >> I like this a lot. It allows us to get configuration into Python without >> being as magical as grok. >> >> One thing I particularly like: knowledge of zcml would easily map to >> this -- and back! That would make it great for teaching. >> >> >> On Fri, Jan 3, 2014 at 12:17 AM, Asko Soukka <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> last year there was (again) a long discussion about pros and cons of >> grok-based configuration: >> >> http://plone.293351.n2.nabble.__com/GROK-RULES-I-WANT-IT- >> MORE-__Was-The-grokless-madness-and-__unable-to-create-a-simple-__form- >> tt7564217.html >> >> <http://plone.293351.n2.nabble.com/GROK-RULES-I-WANT- >> IT-MORE-Was-The-grokless-madness-and-unable-to-create- >> a-simple-form-tt7564217.html> >> >> >> TL;DR; It seems that Grok will never have feature parity with ZCML, >> but it has use cases and we have nothing to replace it. >> >> >> I've been experimenting with an alternative lately: a venusian-based >> configuration library for zope.configuration; All python, minimal >> dependencies, uses the same directive code as ZCML (= feature >> parity), no conventions - just IDE-friendly Python-based configuration. >> >> I'm not forcing this to anyone. An another way to configure may be >> the last thing we need. Yet, I want to try this approach as a >> grok-replacement for our (my employer) internal packages during this >> spring (we'll have new developers and grok has always been easier to >> teach than ZCML). Only for add-on-packages. >> >> So, before spending too much time polishing the code, I'd like to >> request for your comments about the configuration syntax, which I've >> been tinkering: >> >> https://github.com/datakurre/__collective.venusianconfig/__ >> blob/master/demo/src/__venusianconfigdemo/configure.__py >> >> <https://github.com/datakurre/collective.venusianconfig/ >> blob/master/demo/src/venusianconfigdemo/configure.py> >> >> >> https://github.com/datakurre/__collective.venusianconfig/__ >> blob/master/demo/src/__venusianconfigdemo/views.py >> >> <https://github.com/datakurre/collective.venusianconfig/ >> blob/master/demo/src/venusianconfigdemo/views.py> >> >> >> https://github.com/datakurre/__collective.venusianconfig/__ >> blob/master/demo/src/__venusianconfigdemo/adapters.py >> >> <https://github.com/datakurre/collective.venusianconfig/ >> blob/master/demo/src/venusianconfigdemo/adapters.py> >> >> >> https://github.com/datakurre/__collective.venusianconfig/__ >> blob/master/demo/src/__venusianconfigdemo/portlets/__configure.py >> >> <https://github.com/datakurre/collective.venusianconfig/ >> blob/master/demo/src/venusianconfigdemo/portlets/configure.py> >> >> >> >> So, it's not grok. It's a Python-syntax for zope.configuration with >> optional support for limited set of decorators (directives with >> class, factory or handler). >> >> Venusian-library is used to make all configuration directives lazy: >> venusian creates "registration callbacks" during module import, but >> those callbacks are only executed when packages is imported by >> zope.configuration. >> >> >> The current catch is that this needs one line in zope.conf (for >> monkeypatching zope.configuration) and custom site.zcml (for >> z3c.autoinclude also Python-configured packages). These are required >> to work around hardcoded zcml-expectations. >> >> >> Waiting for your comments. >> >> Regards, >> Asko >> _________________________________________________ >> Product-Developers mailing list >> Product-Developers@lists.__plone.org >> <mailto:[email protected]> >> https://lists.plone.org/__mailman/listinfo/plone-__product-developers >> <https://lists.plone.org/mailman/listinfo/plone-product-developers> >> >> >> _______________________________________________ >> Product-Developers mailing list >> [email protected] >> https://lists.plone.org/mailman/listinfo/plone-product-developers >> > > _______________________________________________ > Product-Developers mailing list > [email protected] > https://lists.plone.org/mailman/listinfo/plone-product-developers >
_______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
