On 2013-26-08 24:07, Dustin J. Mitchell wrote:
On Sun, Aug 25, 2013 at 5:45 PM, Henrik Lindberg
<[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.
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.
- 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 [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.
