Platform Team Week of June 8th, 2014

[Andy Parker]

Week of June 8th, 2014

** Next PR Triage Wednesday, June 18th @ 10:00 am Pacific. **

Priorities

  1. Puppet 3.7.0/4.0.0 with the final language polish as well as many other changes.

  2. Windows stability improvements

  3. CFacter on the march

Commentary

PUP-514 has landed! This is a major new feature for the puppet language. You can now specify types on the arguments to classes, defines, lambdas, and EPPs. The type system has been around for a little while now, but until recently wasn't the kind of thing that most people used. Now it is tied much more directly into the language in a way that should let you get rid of a lot of the validate_x() function calls and provide classes/defines that clearly specify what the allowed values are for parameters.

This is a huge new feature. Henrik has been thinking through the type system for a while now and slowly evolving it in the background. You can see his writings on the topic at 

http://puppet-on-the-edge.blogspot.com/2014/02/puppet-internals-puppet-type-system.html. Since this is such a big feature, and so important to the correctness of any manifests that use it, I'd like to ask for some help. Please grab the master branch up puppet and try out converting your manifests to using the types. See what you can express with them, see what you can't. If it behaves in ways that are unintuitive, hard to understand, out write wrong or self-contridictory, please let us know!

The work to convert to using FFI for windows is nearly complete. The build out to getting x64 support is continuing (it requires using ruby 2.0).

CFacter should hit 0.1.0 this week and Facter should get a 2.1 release.

Data

Since we are aiming for the 3.7 release, I'm going to start publishing the version burn-up. It gives an indication about how we are tracking to finishing the known work to a particular date. However, it doesn't do a good job of telling us how we are doing with unknown scope. A lot of the scope growth appears to happen on Wednesdays, which would correspond with our planning and with our PR triage where we pull in tickets.

http://pullrequestmetrics.herokuapp.com/

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Andy Parker]

On Mon, Jun 16, 2014 at 10:40 AM, Andy Parker <an...@puppetlabs.com> wrote:

Week of June 8th, 2014

** Next PR Triage Wednesday, June 18th @ 10:00 am Pacific. **

Priorities

  1. Puppet 3.7.0/4.0.0 with the final language polish as well as many other changes.

  2. Windows stability improvements

  3. CFacter on the march

Commentary

PUP-514 has landed! This is a major new feature for the puppet language. You can now specify types on the arguments to classes, defines, lambdas, and EPPs. The type system has been around for a little while now, but until recently wasn't the kind of thing that most people used. Now it is tied much more directly into the language in a way that should let you get rid of a lot of the validate_x() function calls and provide classes/defines that clearly specify what the allowed values are for parameters.

This is a huge new feature. Henrik has been thinking through the type system for a while now and slowly evolving it in the background. You can see his writings on the topic at 

http://puppet-on-the-edge.blogspot.com/2014/02/puppet-internals-puppet-type-system.html. Since this is such a big feature, and so important to the correctness of any manifests that use it, I'd like to ask for some help. Please grab the master branch up puppet and try out converting your manifests to using the types. See what you can express with them, see what you can't. If it behaves in ways that are unintuitive, hard to understand, out write wrong or self-contridictory, please let us know!

And like so many huge new features, once you step back and start looking at it things take some squinting and then need to be changed.

In the blog posts, Henrik described the system whereby we had 3 types that were not comparable: Undef, Type, and Object. In order to express the "any" type you needed to do Variant[Undef, Type, Object]. This was pretty horrible and so there was a change to make it so that Type was a subtype of Object, which reduced it to Optional[Object]. However, that was still less than ideal and left us with a type system without a singular top type (http://en.wikipedia.org/wiki/Top_type) other than the one that could be constructed using Optional. So recently Object has been promoted to be the top type of the system (this is what is currently on the master branch). However, stepping back, using the word Object is probably going to be a little confusing in a language where nobody thinks about things as objects, but that has "classes" that aren't really OO classes.

So Object is going to remain the top type, but we are going to rename it to Any, which is a much more fitting word and doesn't have any of the associations (that I can think of) to confuse it with "class". I've created PUP-2787 to track this change.

 

The work to convert to using FFI for windows is nearly complete. The build out to getting x64 support is continuing (it requires using ruby 2.0).

CFacter should hit 0.1.0 this week and Facter should get a 2.1 release.

Data

Since we are aiming for the 3.7 release, I'm going to start publishing the version burn-up. It gives an indication about how we are tracking to finishing the known work to a particular date. However, it doesn't do a good job of telling us how we are doing with unknown scope. A lot of the scope growth appears to happen on Wednesdays, which would correspond with our planning and with our PR triage where we pull in tickets.

http://pullrequestmetrics.herokuapp.com/

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Henrik Lindberg]

I am working on a blog post to cover the new type checking features and
the various ways they can be used - either "automatically" by declaring
parameters as typed, or by using the assert_type function when the
declarative approach is not enough. (Hope to have the blog post ready in
a day or so) - it will appear as part of the type system blog posts -
i.e. indexed from this page:
http://puppet-on-the-edge.blogspot.se/2014/02/the-puppet-type-system-blog-posts.html).

> The work to convert to using FFI for windows is nearly complete. The
> build out to getting x64 support is continuing (it requires using ruby 2.0).
> CFacter should hit 0.1.0 this week and Facter should get a 2.1 release.
>
>
> Data
>
>
> Since we are aiming for the 3.7 release, I'm going to start publishing
> the version burn-up. It gives an indication about how we are tracking to
> finishing the known work to a particular date. However, it doesn't do a
> good job of telling us how we are doing with unknown scope. A lot of the
> scope growth appears to happen on Wednesdays, which would correspond
> with our planning and with our PR triage where we pull in tickets.
>

> Inline image 1
>
> http://pullrequestmetrics.herokuapp.com/
>

> Inline image 2

> Inline image 3
> --
> Andrew Parker

> an...@puppetlabs.com <mailto:an...@puppetlabs.com>

> Freenode: zaphod42
> Twitter: @aparker42
> Software Developer
>

> *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
> 22-24 in San Francisco*
> /Register by May 30th to take advantage of the Early Adopter discount
> <http://links.puppetlabs.com/puppetconf-early-adopter> //—//save $349!/
>
> --
> 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+...@googlegroups.com
> <mailto:puppet-dev+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CANhgQXswXMkp2fbHr9AF5KYdHsRWsHnCK-mext5yVE7ttEWcXQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANhgQXswXMkp2fbHr9AF5KYdHsRWsHnCK-mext5yVE7ttEWcXQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Henrik Lindberg]

On 2014-18-06 3:45, Henrik Lindberg wrote:

>
> I am working on a blog post to cover the new type checking features and
> the various ways they can be used - either "automatically" by declaring
> parameters as typed, or by using the assert_type function when the
> declarative approach is not enough. (Hope to have the blog post ready in
> a day or so) - it will appear as part of the type system blog posts -
> i.e. indexed from this page:
> http://puppet-on-the-edge.blogspot.se/2014/02/the-puppet-type-system-blog-posts.html).
>

Just off the presses..

http://puppet-on-the-edge.blogspot.se/2014/06/optionally-typed-parameters.html

[Trevor Vaughan]

Henrik,

Just got done reading through this and it looks quite useful.

I do have a common use case that I'd like to see incorporated if possible though.

I would like to have users be able to input either a String or an Array into many variables and have String instances auto-cast to a single unit Array.

This would allow me to simplify code where I either have to cast the variable myself or have an if/else chain to do different things based on the input type.

Thanks,

Trevor

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/lnsbqa%241bh%241%40ger.gmane.org.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Andy Parker]

On Wed, Jun 25, 2014 at 5:27 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

Henrik,

Just got done reading through this and it looks quite useful.

I do have a common use case that I'd like to see incorporated if possible though.

I would like to have users be able to input either a String or an Array into many variables and have String instances auto-cast to a single unit Array.

You can do something like that right now. The type of the parameter is Variant[String, Array[String]], then once you get the value you need to convert that into a common type. For that kind of a thing, I think there would be a function to convert the type, but I'm not sure that we would put such a function inside puppet itself.

 

This would allow me to simplify code where I either have to cast the variable myself or have an if/else chain to do different things based on the input type.

We've made the decision that puppet will try to have as few surprises as possible in the language and so auto-conversion of values between types is kept to a minimum. The only one we really have right now is Numeric<->String and stringification in string interpolations.

 

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoW80U_HHJmXEW9rpGKQ_Us_K4evmCMhxqcN-JrxqdTLKw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Henrik Lindberg]

On 2014-25-06 18:32, Andy Parker wrote:
> On Wed, Jun 25, 2014 at 5:27 AM, Trevor Vaughan <tvau...@onyxpoint.com
> <mailto:tvau...@onyxpoint.com>> wrote:
>
> Henrik,
>
> Just got done reading through this and it looks quite useful.
>
> I do have a common use case that I'd like to see incorporated if
> possible though.
>
> I would like to have users be able to input either a String or an
> Array into many variables and have String instances auto-cast to a
> single unit Array.
>
>
> You can do something like that right now. The type of the parameter is
> Variant[String, Array[String]], then once you get the value you need to
> convert that into a common type. For that kind of a thing, I think there
> would be a function to convert the type, but I'm not sure that we would
> put such a function inside puppet itself.
>
> This would allow me to simplify code where I either have to cast the
> variable myself or have an if/else chain to do different things
> based on the input type.
>
>
> We've made the decision that puppet will try to have as few surprises as
> possible in the language and so auto-conversion of values between types
> is kept to a minimum. The only one we really have right now is
> Numeric<->String and stringification in string interpolations.
>

I don't think the value transformation part is something we want to
support in general for a parameter; similar things can be done in a
(ruby) resource type. We are looking into how you can specify types in
the puppet language, I can imagine things like this being one there,
were you declare a type to have derived attributes (they are computed),
while you have the real user entered data in an attribute with storage,
or the other way around, a complex value is split up on assignment, and
(possibly) put back together when reading it.

Basically I envison these types to have functions (written in the puppet
language) inside them for things like derived values, munging,
transformation.

I expect the types to be callable to create new instances. Say you
invent your data type that accepts Variant[String, Array[String]] when
created, and then maps that to always be multi valued. You would give it
an apropriate name - here inventing Strings as the type - the user
writes Strings('one string'), Strings('one string', 'another'), or
Strings(['one', 'two', 'three']), or whatever you feel like supporting.
The receiving end then naturally only accepts something of Strings type.
You know do not have to do any checking since all transformations are
done in the Strings type.

(These ideas are not fully worked out, but I imagine something along
those lines).

If you like to write a assert and transform function (right now) that
would not be too hard, but you would miss the convenience of directly
typing the parameters (except for the checking that can be made with
something like Variant[String, Array[String]].

I don't see us adding automatic data conversion for parameters; although
convenient from one vantage point, it is also a constant source of
problems, causes performance issues, and can be mysterious to users.

- henrik

[Trevor Vaughan]

Thanks for the replies. This all makes sense and I think I'll stick with the Variant technique for as many scenarios as possible.

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/lofiji%242sg%241%40ger.gmane.org.

For more options, visit https://groups.google.com/d/optout.