On 25 August 2013 15:47, Henrik Lindberg <[email protected]>wrote:
> On 2013-26-08 24:07, Dustin J. Mitchell wrote: > >> On Sun, Aug 25, 2013 at 5:45 PM, Henrik Lindberg >> <henrik.lindberg@cloudsmith.**com <[email protected]>> >> wrote: >> >>> This may be silly, but "Extended Puppet Templates" seems more logically >>>> abbreviated "EPT" - why "EPP"? >>>> >>>> Does it say "Extended Puppet Templates" somewhere? The idea is to do >>> the >>> same as in Ruby, i.e. "Embedded Ruby" = ERP, "Embedded Puppet" = EPP. >>> >> >> I should have said "Embedded", not "Extended". And, fair enough - >> Embedded RuBy templates are not "ERT", they are "ERB". So Embedded >> PuPpet templates can be "EPP". >> >> i.e. it is using the original file extensions .rb, and .pp and prepends > an 'e' for embedded. > > > Could you include a link to the Puppet DSL in the text? It's easy to >>>> think that that means Puppet itself (e.g., resource declarations), when >>>> really it is a form of Ruby (I think). The link will add context. >>>> >>>> Sorry, but I don't get your question. EPP is to Puppet what ERB is to >>> ruby. >>> The EPP content is in a file, typically with extension .epp, but can be >>> anything except .pp (which is naturally "not embedded puppet code"). >>> >>> But, I think you are asking something else... >>> >> >> I'm asking, what language do I use between <% %>? Can I write >> >> <% >> file { >> '/etc/motd': >> content => "hello, world\n" >> } >> %> >> >> At the technical parsing level, yes. This is then validated to only > include what we want to allow. The first implementation is very permissive. > > > which is what "Embedded Puppet" suggests to me. That's not the case, >> and "Puppet DSL" is only slightly less unclear, unless the reader is >> enough of a Rubyist to realize that "DSL" in the Ruby community refers >> to a modified Ruby environment, and not an entirely different >> language. Basically, please add a link so I know unambiguously what I >> can and cannot do between <% .. %>. >> >> All Puppet DSL expressions that do not require "top level" (i.e. class > and define) can be used. They don't require top level in puppet manifests, this should be legal: class foo { class bar { ... } } just that it declares the classes foo and foo::bar, not foo and bar. Is this somehow disallowed in epp? node statements requires top level though afaik. > > > As for validation of filetypes, I think this is a good idea, but I don't >>>> like the <%- ($x, $y) :html -%> syntax for this. I'd prefer something a >>>> little more explicit and expandable, perhaps >>>> <%- ($x, $y) syntax => html -%> >>>> >>>> The idea was to mimic the same specification in ARM-4 Heredoc, where >>> the >>> syntax is ':syntax'. >>> >> >> I could make the same criticism there (I just haven't gotten to that ARM >> yet). >> >> Fair. It should be the same/similar though - and in the heredoc case > there are additional constraints since the construct is "parsed" by the > lexer. > > > I am not super happy with the somewhat magic <%- () -%> construct. It >>> allowed me to reuse parameter parsing. Did not spend too much time on >>> figuring out alternatives, but the ones that came to mind I thought were >>> worse. >>> >> >> In the absence of other data, explicit is better than implicit: >> >> <%- params => ($x, $y), >> syntax => :html -%> >> >> Yeah, but then a different tag is required since the text is not valid > Puppet DSL syntax, or new Puppet DSL syntax is required that is specific > for a "template function" which this essentially is. > > Will look at it again. > > > Whether it should be restricted scope of not by default I don't know. It >>> could be a chore to have to write a hash with name to value associations. >>> >> >> EPP doesn't need to inherit the warts of ERB, at least not by default. >> > Totally agree. > > > If backward-compatibility is easy but not the defalut, then new users >> will not accidentally use the deprecated feature - at least not >> without careful thought. >> >> In Python, if you wanted to pass your local variables to a called >> function, you could use something like >> >> called_function(**locals()) >> >> Which is explicit (and very rare). I don't necessarily think that EPP >> should use the ** syntax, but certainly using an explicit option for >> the behavior is possible. >> >> Internally there is a way to get a hash map of all variables in scope; a > simple function could be implemented if this is needed. > Have to think more about a restricted scope feature. > > > There is a Redmine issue where it is discussed if it is good or bad that >>> the >>> template functions can join results from multiple templates. I would >>> prefer >>> if it was just one, and instead call a join function if that behavior is >>> needed. >>> >> >> I think the sticking point on that bug is that the change would be >> backward-incompatible. The same is not the case for EPP. If the EPP >> functions *never* concatenate by default, then users converting from >> ERB templates will need to manually apply the concatenation during >> conversion. >> >> With future parser and iteration it is quite easy. > ['file1', 'file2', 'file3'].collect |$file| { > epp_template($file) > }.join('') > > Or some variation thereof. > I can also imagine passing an array of files (instead of just one file) > with the meaning "please join the result of these". This was not convenient > in the old parser as you had to assign the array to a variable first. in puppet version 2.6.8+ anonymous arrays and hashes should be allowed, so that worked in recent versions of the old parser as well. -- Erik Dalén -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
