On 2014-03-08 22:22, Luke Kanies wrote:
On Jul 28, 2014, at 7:33 AM, Henrik Lindberg <henrik.lindb...@cloudsmith.com>
wrote:
On 2014-28-07 8:34, Luke Kanies wrote:
On Jul 24, 2014, at 5:32 PM, Andy Parker <a...@puppetlabs.com
<mailto:a...@puppetlabs.com>> wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty
epic conversations around resource expressions, precedence, order of
evaluation, and several other topics. What kicked all of that off was
us looking for some feedback on decisions we were making for the
Puppet 4 language about how resource overrides, defaults, and so on
actually work (or don't in some cases). I think we've finally reached
some decisions!
Henrik took all of the ideas and started trying to work out what we
could do and what we couldn't. Those are in a writeup at
https://docs.google.com/a/puppetlabs.com/document/d/1mlwyaEeZqCfbF2oI1F-95cochxfe9gubjfc_BXjkOjA/edit#
Sorry for the late comments here, but I have a couple of questions and
comments.
Lots of information in there, so here is the summary.
The principles behind the decisions:
1. Only make changes that have a high likelihood of *not* needing to
be backed out later.
2. Strict or explicit is better than lax or implicit. It uncovers
issues and keeps you from lying to yourself.
3. Puppet 3 has already stacked up a lot of changes. Do not break
manifests unless we really have to.
4. Let's not break manifests and then have to break them in almost
the same way once we start working on a new catalog system.
Great principles. It would be good to see these paired with what fits
into the "we really have to" section of #3.
Mostly, the "we have to" issues are those that relates to strictness, where it
previously was relaxed and/or had undefined behavior.
Ok. Again, it would be good to see those documented.
They are - see the documentation for the future parser. For 3.7 future
parser this documentation is not yet produced, so it is a matter of
looking at closed tickets. (Most breaking changes were done prior to 3.7
future parser).
From the top of my mind..
Earlier breaking changes include:
* Numbers are Numeric and must be valid numbers, quote them if they
should be strings.
* An upper cased bare word is always a reference to a type (must be
quoted if you want it to be a string).
* You are no longer allowed to add to arrays and hashes (they are immutable)
* Bugs in operators +, -, *, /, in, >, <, <=, >=, ==, and != could
produce odd results, and if you relied on those quirks the fixes could
be perceived as breaking change.
* =~ and !~ requires the LHS to have String result (it does not
stringify before matching)
* You cannot have a class or defined type named 'class'
* You cannot assign to numeric variables (i.e. $1 = 10)
* Names of classes and defines cannot start with a digit
In 3.7:
* Undef is no longer equal to empty string
* Empty string is truthy
* Attribute names 'false', and 'true' are no longer accepted
[...]
DECISION SIX
There will be a splat operator for resource instantiation expressions
To make the default resources (decision five) really useful there
needs to be a way to reuse the same values across multiple defaults.
The current, dangerous, semantics of resource default expressions
skirt this issue by making defaults part of the (dynamic) evaluation
scope. In order to make the default resources nearly as useful but
much safer, we need to add a way to allow reuse of defaults across
multiple resource instantiation expressions explicitly (principle 2).
$owner_mode = { owner => andy, mode => '777' } # gotta make it secure
file { default: *=> $owner_mode;
'/home/andy/.bashrc': ;
'/home/andy/.ssh/id_rsa': ;
}
file { '/etc/passwd': *=> $owner_mode }
As a side note, do you see what can now be done?
$a = notify
$b = hi
$c = { message => bye }
$a { $b: *=> $c }
As above, this makes the language much more powerful and complex, and it
seems like makes it possible to build truly unreadable code without
trying very hard.
What's the use case for this, and why is that use case important enough
to justify this increase in complexity?
This is to support what is otherwise done in an opaque fashion with Ruby
templates, or calling the create_resources function. It is mostly done by
module authors that integrate with other modules, and where it is not known at
authoring time what the name of the type is.
It allows allows a transformation of data to resources to be expressed in the
puppet language. Again, the alternative is to transform to a generic hash and
then call create_resources. Sometimes people create their own variants of
create_resources as custom function because it
has been difficult to perform such transformations in the puppet language..
We believe that the ability to have indirection for the type is a better
solution than the alternatives, even if looks more complex, it makes the logic
visible and reduces the dependency on Ruby.
I am not convinced. Based on what I've seen so far, I prefer transformation to
a hash, and using a function. This is a lot of syntactical power, and it is
being done to replace what seems like relatively simple hash operations and a
simple function.
I know this wouldn't cover every case, but wouldn't it cover the majority of
cases, and thus be a better trade-off? That is, we have a somewhat less
powerful language, but a much more accessible language, and it comfortably
covers the 95%+ use cases while still being usable by 95%+ of its users?
My main objection with create_resources function is that it is not a
natural progression from the language. When developing puppet code, you
start out with simple resources and use the syntax for creating them. As
you are building up your modules and complexity increases you reach a
point where you have to redo what you have already done because now you
have to instead construct a hash and call a function.
When you have reached this point several times, you are more likely to
always use create_resources.
When instead directly supported in the language, you can add the more
advanced things if and when they are needed.
Having the power to do so, does not take anything away.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lrmgq9%2423k%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
