[Product-Developers] RFC: Venusian-based Python-syntax alternative for ZCML-configuration

[Asko Soukka]

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 <asko.soukka at iki.fi
> <mailto:asko.soukka at iki.fi>> 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 at lists.__plone.org
> <mailto:Product-Developers at lists.plone.org>
> https://lists.plone.org/__mailman/listinfo/plone-__product-developers
> <https://lists.plone.org/mailman/listinfo/plone-product-developers>
>
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-product-developers