>> > And IMO, that's as it should be. Back end ruby language code should be >> > held >> > separate from regular "puppet language code" stuff. >> >> I'm still not convinced, but I'm open to being convinced :-). >> > > Here's the important factor, which you guys @puppetlabs simply cannot see, > because you've been steeped in it so long: > > "puppet language", and ruby, are *two* *separate* *languages*. > Similar, yet different. Each with slightly different quirks. And in addition > to that, there's (plain ruby), and then there's (ruby + puppet back-end > code). > Which is a smaller scale equivalent of (C language, plus > insert-toolkit-lib-here) > > Try to picture a sysadmin. a reasonably competant sysadmin. But one who has > zero prior experience with ruby, or puppet. > > Now try to imagine this person attempting to fully understand puppet. > > To *fully* undestand it, he has to try to learn 2.5 brand new languages. > > Which is made even more difficult by the "minor detail", that > NO-ONE TELLS HIM THEY ARE DIFFERENT.
I would have thought that file extensions were enough to indicate language change. Puppet manifests end in 'pp' and ruby files end in 'rb'. Also - be mindful - that puppet code lives in 'manifests'. And ruby code lives in 'lib'. We could always rename 'lib' to 'ruby', but we didn't want to be specific. > This is enough to make even a highly competant sysadmin run away screaming. I don't think that pure ruby resources are necessarily aimed at sysadmins - although one day I would love to simplify them to such an extent. They are today, without a doubt - the more difficult extension within Puppet and do require some reasonable Ruby knowledge to write. In fact we do dedicate for this reason most of our development training course to this. The alternative however is to simply use the lighter 'defined resource' approach which is a pure Puppet DSL solution to writing resources, which often gets a reasonable mileage - albeit you lack some nicer features. > In fact, I myself did, some years ago. But I've had enough motivation to > come back and give it another go lately. I'm glad you have given it a second chance. > Point of reference: > I've been in the industry for 20 years. > I have a computer science degree. > I know approximately 10 diferent computer languages, and 3 real world ones. > I've written device drivers, and 5,000 line shell scripts. > > if it was difficult for ME to understand and separate, contextually... how > difficult do you think it will be for the average sysadmin who has zero ruby > experience, etc? Again - I don't think we hide the fact that resources aren't for the 'average sysadmin' to write. Its a terrible shame - but there we are. I wouldn't mind at some point a relook at the API for writing resources, but they are still in effect Ruby components and follow ruby rules. I have pondered the value in fact of extending the defined resource concept in Puppet DSL to extend its capabilities so it gets closer to pure ruby resources. But yes - as you have stated it sounds more like we need to extend the documentation for writing resources a little more at least so people have good examples to follow along to. > Because of this, I'm saying it is really really important to have clearly > defined borders between "frontend" puppet language > (the language of manifests) > and backend (ruby, and related puppet code) > Simply for the sanity of any poor admin who attempts to read this stuff, and > doesnt realize he's stepped over into an entirely different language > country, when he changed files. > Because after all, "they're all just a 'puppet module', right? so they're > all the same language". Puppet code ends in .pp, ruby in .rb - manifest code belongs in 'manifests' and Ruby code belongs in 'lib'. Is there need for further clarification? Btw - templates belong in 'templates' and files in 'files'. Although these are more aptly named :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
