'application' is now a reserved word? wtf

[Chris Rigby]

Hi, 

So I have a class called `application`, and literally hundreds of subclasses called `application::something` and now I've just learnt that 'application' is now a reserved keyword in a point release. (3.8.2). 

What's going on? Are we all relegated to updating countless manifests that used to work fine because someone made the brash decision to use 'application' (which in itself is ambiguous) as a reserved keyword? 

[John Bollinger]

On Thursday, August 13, 2015 at 9:57:31 AM UTC-5, Chris Rigby wrote:

Hi, 

So I have a class called `application`, and literally hundreds of subclasses called `application::something` and now I've just learnt that 'application' is now a reserved keyword in a point release. (3.8.2).

What a mess.  According to the relevant section heading in the v3.8.2 release notes, 'application' (and 'consumes' and 'produces') are deprecated for use as bare words in 3.8.2, but the text of the notes explains that they are indeed reserved when the future parser is used.  I guess this is technically kosher given that the future parser is not guaranteed stable, but it is NOT NICE.

More troubling, however, is the plan to introduce these new reserved words into the Puppet 4.2.2 point release.  That's a breaking change, and as such it should be made only in conjunction with a new major release.  I can personally attest that Chris is not the only person who has a module named 'application', and it must be assumed that that word and the others are used as bare words elsewhere among the many Puppet installations, too.  Even the issue description is flagged as a "new feature" (though it's not clear what's featureful about it), so even if its breaking nature were not recognized, at minimum it should have to wait for a minor release.  In the 3.8 series, too.

 

What's going on? Are we all relegated to updating countless manifests that used to work fine because someone made the brash decision to use 'application' (which in itself is ambiguous) as a reserved keyword? 

Is it indeed intended that these words will be reserved for use as class and type names?  The issue's description couches it in terms of bare words vs. quoting, which is relevant to values, but if class and type names are also affected then that's a much more impactful change, admitting situations that are not so easily reparable.

So, yes, what's going on?


John

[Chris Rigby]

My issue in particular is related to a bug introduced into the future parser in 3.8.2. 

The bug breaks compilation when using a reserved keyword as a classname when the future parser is enabled. 

See https://tickets.puppetlabs.com/browse/PUP-5036

[Ryan Coleman]

On Thu, Aug 13, 2015 at 3:10 PM, Chris Rigby <squ...@radioglitch.com> wrote:

My issue in particular is related to a bug introduced into the future parser in 3.8.2. 

The bug breaks compilation when using a reserved keyword as a classname when the future parser is enabled. 

See https://tickets.puppetlabs.com/browse/PUP-5036

​Chris, I'm still gathering a few details for a more complete reply but in the interim, I'd like to say the intent was to offer a warning which does seem to have a bug. This is also discussed in the ticket which introduced the reservation: https://tickets.puppetlabs.com/browse/PUP-4941

I'll reply shortly with more on the reasoning for the change. 

[Ryan Coleman]

Hello again Chris, 

We’re moving to reserve the words application, produces and consumes as keywords for a future addition to the Puppet language. Similar to the major additions in Puppet 4, we’re trying to provide as much early warning as possible so that adjustments can be made as needed when you’re working on your code base. In this situation, the intent is to provide warnings when those words are used with Puppet 3.8.2 —parser=future. Unfortunately, you’ve encountered a bug that will be addressed promptly. Sorry about that. 

As for the reason, we’re spending some time thinking about how to model multi-node configurations. Though we’re a couple of months away from concrete details, we know enough to begin to signal the reservation of new keywords. A few of the ideas have been expressed by Luke Kanies in PRFC-6 and David Lutterkort in a talk he gave at CfgMgmtCamp’15.

[1]https://github.com/puppetlabs/puppet-rfc/blob/master/prfc-6.capabilities/capabilities.md

[2]http://www.slideshare.net/lutter/appmgmt-cfgmgmtcamp2015

[Miguel Di Ciurcio Filho]

On Thu, Aug 13, 2015 at 9:02 PM, Ryan Coleman <ry...@puppetlabs.com> wrote:
> As for the reason, we’re spending some time thinking about how to model
> multi-node configurations. Though we’re a couple of months away from
> concrete details, we know enough to begin to signal the reservation of new
> keywords. A few of the ideas have been expressed by Luke Kanies in PRFC-6
> and David Lutterkort in a talk he gave at CfgMgmtCamp’15.

I've just read the PRFC-6 and read the slides. By these new reserved
words and what the RFC says, if I've connected the dots correctly, my
mind is blown.

[Pete Brown]

On 15 August 2015 at 11:35, Miguel Di Ciurcio Filho

Yep.
That is indeed pretty cool.

And as to the original point.
It's pretty easy to refactor class names between releases of your
management code.
The whole point of nicely versioned infrastructure is you can do stuff
like that and not break anything.
The class names that encompass your resources don't actually mean
anything, it's the functionality of those resources that counts and if
the resources in your classes don't change it's easy to move them
around.
I have moved resources from class to class many times and it hasn't
broken anything.
Same thing goes for defines.

If you aren't versioning all your modules then It's a good time to start.

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAK6Ystmp__7yV_GLTO40teAsquxxNmEWPSkF8vQSK0O0zKcBYQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



--
--
Pete Brown
Director and Primary Infrastructure Developer
Abstract IT Pty Ltd.

LinkedIn: https://au.linkedin.com/in/rendhalver
GitHub: https://github.com/rendhalver