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

Asko Soukka asko.soukka at iki.fi
Mon Jan 6 07:25:00 UTC 2014


Hi Dylan,

Dylan Jay wrote:
> 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 do use conditional imports and I don't see the real issue here (yet).

I think, this is mainly a problem from recursive scan. If you do scan 
per file, you can have conditions just normally. With Grok,
you can already use:

     <grok:grok module=".foobar" zcml:condition="installed ..." />

Of course, in Python, you need to be more verbose:

     try:
         pkg_resources.get_distribution('...')
     except pkg_resources.DistributionNotFound:
         HAS_SOMETHING = False
     else:
         HAS_SOMETHING = True

     if HAS_SOMETHING:
        import module
        scan(module)

Alternatively, you could group conditional imports into a subpackage
and do normal conditional include:

     import subpackage  # does nothing with empty __ini__.py
     configure.include(package=subpackage, condition='installed ...')

You could also still do just

     configure.include(package='.subpackage', condition='installed ...')

but using strings instead of references takes away one point from using
Python configuration. Still, it might make sense when using just a 
separate configuration file, like:

     configure.include(file='configure_extras.py',
                       condition='installed ...')

(A side note: I'm not sure if an implicit condition-argument is the best 
way to support zcml-conditions, but that's what I have for now.)

So, personally, I think that having a separate configuration file 
(configure.[zcml|py]) is more important than separate language.

Regards,
Asko

> 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" <asko.soukka at iki.fi
> <mailto:asko.soukka at iki.fi>> 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 <asko.soukka at iki.fi
>         <mailto:asko.soukka at iki.fi>
>         <mailto: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
>         <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/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/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/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>
>
>         <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.__plo__ne.org <http://plone.org>
>         <mailto: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>
>         <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
>         <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
>     <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>
>



More information about the Product-Developers mailing list