On 2014-10-04 23:19, Ken Barber wrote:
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $::environment |>> #
dalen's suggestion
Nah, that goes down the path of using different syntax and even terminals in
queries.
Myresource <<| _environment == $::environment |>> #
alternate to dalen's suggestion
Nah, a NAME, cannot start with _
Actually, the parser breaks on all of these suggestion:
https://gist.github.com/kbarber/10423111
Myresource <<| catalog.environment == $$::environment |>> # implies
that 'catalog' is an object with subparameters
Better, still has $$.
Yeah that was a typo I had just copy/pasted.
Myresource <<| Environment == $$::environment |>> # ye old
capitalization like other parts of puppet
Environment would by general rule be a type, and typically would mean
any Environment. Confusing.
Myresource <<| same_environment? |>> #
short-hand for matching the same environment
Introduces a name that ends with ?, not supported.
Well, whatever we use, the idea of being a single item for matching
current environment. Alas I doubt the parser would allow it.
Of the proposals above, the one that introduces catalog.environment is
closest to what is supportable.
Alas, it is not. Currently it seems that anything that we could
choose, would have the chance of collision with a real parameter.
If a query of
Resource <<| Q |>>
means resolve against all environments, then
Environment[production, Myresource] <<| Q | >>
could mean, resolve the query in the given environment.
If we like to have resolution of variables that only exist in the query
that is also an option, like the reference to catalog, but I would like that
to be $catalog. i.e. inside the spaceship, when a query is evaluated it can
have access to things that we would like a user to be able to reference and
access details. The details should be obtained using the [] operator since
this is what is used for this purpose everywhere else.
Other options are to use function calls inside the spaceship. They are not
supported now as valid in a query and would be unambiguous and easy to
transform into whatever we want them to mean. These are query functions, not
general puppet functions.
e.g.
# a given environment
Myresource <<| environment(production) |>>
# current environment
Myresource <<| environment($environment) |>>
Myresource <<| environment() |>>
Myresource <<| environment(default) |>>
Remember that the 3x parser has a very brittle grammar, and we do not want
to introduce something that will clash with the future parser grammar. We
especially do not want to mess with terminals.
So none of the ideas I had above will actually work in the current or
future parser anyway.
true.
The 3x/current parser is very picky what it allows in the query. The
only chance of doing someting special, is to reserve some particular
expressions that would otherwise be interpreted as a regular query -
i.e. checking equality on a virtual parameter name or something like
that. This is both messy, and error prone, and not probably not
easier to implement than the alternatives (i.e. change the 3x grammar if
this is to appear before Puppet 4).
If considering changing the 3x grammar to accept
Environment[name, Resource] as its LHS seems quite doable, if the rest
can remain the same. This would be compatible with the future parser
language wise. (In 4x we just have to do whatever is needed in the
transformation to the query API).
The other suggestion (a "function call") is probably the same amount of
work in 3x, and also easy to deal with in 4x.
I figure:
* We could use something like catalog_environment overriding the
ability to collect on a real catalog_environment parameter in the slim
chance of a collision.
* Fix the language to support something going forward, future parser style.
The latter will take some time, and probably involve you directly
Henrik for the design.
I will be glad to help with that.
With the future parser there is a lot more leeway - this because it is
the validation steps that forbids constructs that are illegal
semantically in the Puppet Language, but still parses (following the
principle, "I hear what you are saying, and you are wrong because", as
opposed to going "na na na na, can't hear you"... anyway...
Internally syntax wise it is something like:
CollectionExpression
: Expression Query ('{' ... '}')?
;
Query
: '<|' Expression? '|>'
| '<||' Expression? '||>'
;
i.e. there is a lot of flexibility when parsing. The query operators
have higher precedence than most operators, but you can always put an
expression in parentheses - e.g.
(1+2) <| query |>
Even if that particular example is meaningless, a function call is not
(one that returns the type to query), or a variable expression - e.g.
$x = Environment[production, File]
$x <| ... |>
Note that the query is just one Expression, i.e. parser wise it could be:
a + b * 3 == 4 and foo(1,2,3) + bar or true != false and blah(blah)
The validator kicks in after parsing and raises errors for anything that
is illegal. The validator has one particular way to treat the expression
allowed in a query. Thus to experiment, you would need a tweaked
validator. (Not hard to do when playing with it/ trying things out)
If you want to go out on a limb - calls supports lambdas, and those can
be transformed to something else (think clojure...) that way you could
send a function to execute on the server. Validation can ensure that it
only contains supported expressions....
I think there is a lot that can be done wrt supporting queries expressed
in the Puppet Language.
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/li77pr%24j8l%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
