<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/9/2017 2:35 PM, Doug Hellmann
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1507577515-sup-9944@lrrr.local">
<pre wrap="">Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
</pre>
<blockquote type="cite">
<pre wrap="">Hello Oslo team:
The Mistral project has an expressions package [0] that is used to
evaluate inline expressions using a context. It has a pluggable
architecture that presently supports Jinja and YAQL expression
evaluation. It also allows custom functions[1] to provide Python
implementations of functionality that is then made available to the
expression evaluation engines.
This functionality was originally developed to support dynamic
processing within Mistral workflows, but is also very useful in other
applications that use templates which require runtime evaluation of
expressions.
I'd like to explore extracting this functionality from mistral to make
it more widely available with minimal dependencies.
The expressions dependencies are pretty limited:
Jinja2
oslo.utils
oslo.log
stevedore
yaql
and since 60% are already oslo-maintained packages, it seemed like a
logical place to start.
I'd appreciate feedback on the topic. There is no real OpenStack
dependency in the functionality, so maybe a standalone package on pypi
makes sense.
Thanks for your help,
Bob Haddleton
[0] <a class="moz-txt-link-freetext" href="https://github.com/openstack/mistral/tree/master/mistral/expressions">https://github.com/openstack/mistral/tree/master/mistral/expressions</a>
[1]
<a class="moz-txt-link-freetext" href="https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63">https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63</a>
</pre>
</blockquote>
<pre wrap="">
Oslo is a good place for things like this that have no other obvious
home, but if the Mistral team is already managing the code is there any
reason they couldn't also manage the library after you pull it out of
the service? It's much easier for any project team to manage a library
now, and we have several other examples of that pattern already.
Doug
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
Hi Doug:<br>
<br>
That's probably fine, we're just not sure what the process should be
and where the library would land? Do you have an example that we
could use as a pattern?<br>
<br>
Thanks<br>
<br>
Bob<br>
<br>
</body>
</html>