On Aug 15, 2013, at 9:33 AM, Henrik Lindberg <[email protected]> wrote:
> On 2013-15-08 6:20, Dustin J. Mitchell wrote: >> This is regarding ticket 5517. Briefly, that ticket identifies a corner >> case of parameterized classes and inheritance that behaves unexpectedly >> with no warnings or error messages. The ticket has evolved from "please >> fix" to "please warn or treat as an error" to "parameterized classes >> were never a good idea anyway, let's kill them". >> >> Pardon me while I vent a little. >> >> Puppet has a long history of introducing new features that reference >> some conceptual underpinning, then uncovering major flaws and failures >> to completely implement the conceptual model, deciding they don't work >> at all, and deprecating them. To name just a few: inheritance, >> parameterized classes, stored configurations, global variables (or >> depending on who you ask, variables in general), Ruby DSL, ENCs, >> extlookup, Hiera 1. Some of these technologies died within months of >> being introduced! >> >> This is incredibly abusive to Puppet's users, who must either constantly >> rewrite their manifests to suit the latest hotness before it gets cold, >> or not upgrade to versions of puppet that no longer support features >> they use. >> >> Now, I know software development is hard, and that the core Puppet >> development team pushes pretty relentlessly forward, and that a lot of >> development comes from community members submitting patches with subtle >> bugs or model mismatches that get past review and QA. Nobody's >> perfect. I know that semantic versioning helps users to make >> compatibility predictions based on version numbers. I know that the new >> parser - and a lot of Henrik's other work - builds a base for real, >> formally defined behaviors that can be supported long-term. I know that >> ARMs are meant to open a space for careful thought and discussion of new >> features and their implications for the future. Basically, I'm venting, >> but I realize that improvement is already occurring and I'm grateful for it. >> >> What I've been missing is an explicit conversation about what I see to >> be a substantial problem, and the ways we can all help fix it. I'll >> give a start to the latter: >> >> 1. We should all read ARMs early and critically. I've certainly failed >> on this count. >> 2. We should resist the urge to admit defeat on (mis)features already >> implemented, and look for creative ways to fix their warts. >> 3. When we do admit defeat, surrender completely and spend a *lot* of >> effort making sure the new way is the right way - the cost to users is >> huge, so make it count. >> > Totally agree with your summation. > >> Looping back to #5517, IMHO >> it's not time to give up on parameterized classes, so let's fix the wart. >> > Unless it was clear earlier; I have nothing against parameterized classes per > se - it is just that there are cases where "include" vs. "resource like" > instantiation of the class clashes. There are options: > > a) (now) Silently ignore problem > b) Report problem as an error > c) Deprecate the "resource like" instantiation in favor of data-bindings > d) Something else... but what? I think the best option is relatively simple: a) Switch class evaluation to lazy evaluation plus evaluation on demand. That is, default to lazy evaluation, but be a bit less lazy about it. E.g., if anyone asks for the class's namespace or anything like that, then evaluate the class. Then, in addition, throw an error (or maybe warning?) any time someone tries to override a class that's already been evaluated. And, in fact, I'd start with that second thing - start throwing warnings right now, and as quickly as possible switch to the more intelligent lazy evaluation. Are there reasons why this approach won't work? > I am contemplating a "dependency graph" approach - but not sure it will work > because it is most likely self referential. (i.e. who is using which named > object (class, variable, etc) where) and letting that determine the order of > evaluation. Not sure this approach can be made to work. -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 Join us at PuppetConf 2013, August 22-23 in San Francisco - http://bit.ly/pupconf13 -- 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.
