>> 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. 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. ken. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE4bNT%3D82TRa14qAVNzmA-dvmdgpRA2ySy-QBwdL%3DjWc73iOow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
