>> 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 puppet-dev+unsubscr...@googlegroups.com. 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.
