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.sou...@iki.fi
<mailto:asko.sou...@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.sou...@iki.fi
<mailto:asko.sou...@iki.fi>
<mailto:asko.sou...@iki.fi <mailto:asko.sou...@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@lists.__plo__ne.org <http://plone.org>
<mailto:Product-Developers@__lists.plone.org
<mailto:product-develop...@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@lists.__plone.org
<mailto:product-develop...@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@lists.__plone.org
<mailto:product-develop...@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-develop...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-product-developers
