Sorry for the previous HTML email.
On Fri, Jan 7, 2011 at 1:41 PM, R.I.Pienaar <r...@devco.net> wrote:
>
> You cant avoid the scoping issues cos its broken. You can work around them
> though.
>
> You can be careful about where you set variables and how you include things.
> This
> isn't new we've been doing it for years.
>
> You can use extlookup to fetch variables from your data store in the class
> you need
> it and not rely on setting variables in one scope and accessing them in
> others.
>
> You can have some very simple syntax and style rules that says include
> classes first
> in your class then set variables to avoid the strange ordering issues.
>
> You can create wrapper classes that include other classes but not set
> variables.
> class apache includes apache::config, ::install and ::service and as above in
> each
> case where you need to know apache version or something you can get that from
> extlookup
> which gives you configurable classes today without the scoping issues.
>
> By arranging modules like this - one class that exist only to include other
> classes -
> you totally avoid issues like setting defaults bleeding into other scopes. I
> have 100+
> modules and never even realized the defaults propagate over included classes
> because
> my coding style and standards simply doesnt allow that to happen.
>
> We've avoided these issues for years and the techniques are well known.
Yes, I'm starting to see I took the "easy way" out by just
recommending switching to parametrized classes. They force you to put
the class in only one place since you can't re-declare them. As you
point out, this results in a difficult to easily use class structure.
Bad code.
Given Puppet 2.6.4 language features, is the general idea is to have
init.pp in each module include all of the classes contained within
that module in the order the author determines?
If two modules have a relationship to each other, then would you have
module "a" include only the module's initial class "b" and not a
specific class within module b, like "b::ssl" ?
I've played with this organization structure quite a bit, and I find
myself lot of wrapper and "pass-thu" classes to arrange things. It is
harder for a module author to "get right", but this is definitely
preferable to making it harder for a module consumer to use the
module.
> Now when the language wish to get new features and improve itself you can
> either introduce
> a whole slew of new syntax, deprecate old syntax etc and new ways of writing
> manifests
> or you can fix the scoping problems which will result in existing techniques
> and language
> features working sanely?
I absolutely prefer fixing the scoping issues to the alternatives you
mentioned and I myself have been recommending.
> > Scoping issues trump the inconvenience of specifying this sort of
> > thing when using the classes.
>
> Correct, lets fix the scoping issues that's creating a language that forces
> us to write
> non obvious, non DRY and code that is coupled in ways it shouldnt be coupled.
> We cannot
> now write really advanced modules that hide all the implimentation details
> even though
> the language has all it needs to do this. Whats preventing us from doing
> that is the
> scoping bugs. So I am not sure why we arent fixing these instead.
OK, so what if declaring* a class always added it to the top scope?
This seems like a relatively straight forward solution to a great many
concerns. The language doesn't change, existing manifests continue to
work and only the convention of relying on the order of variable
definitions is affected. The problem of resource defaults also almost
entirely goes away too. This was proposed in the original discussion
about scoping back in July and I'm just curious if there's any new
information in this area.
Similarly, we could leave include as is and add (and recommend the use
of) something like "includetop" which always adds the class to top
scope. This would allow people relying on the current scoping
behavior to remain unaffected.
The other idea I had was to allow classes to be declared virtually,
but this drastically affects existing puppet code and makes the
language harder to learn. (What the heck is @class { foo: }, Class <|
title == foo |> doing!?)
* To me, include foo and class { "foo": } are both "declaring" the class.
--
Jeff McCune
http://www.puppetlabs.com/
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
