----- Original Message -----
> Sorry for the previous HTML email.
no worries, usually I take the time to add extra >'s to make them readable
but when they're long it becomes too much and I give in to the top posting
temptation :)
> 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.
The new relationship chaining syntax goes a way towards this, really I
think if you have a class to install a webserver you should be able to
say use that and it should be a standalone thing that sets up a webserver.
now if you have a foo module - lets say some internal webapp that you deploy
and it too needs a webserver then it should specify relationships with the
require keyword or require on resources. It's up to the situation though
i dont think there's always a right answer. There's going to be edge cases.
A lot of the kind of approaches we do we shouldnt do, they're learned on by
spending hours with test.pp's and discovering the pifalls, they're not
documented and if you tell a new person that just to install ntp he needs
to make 3 classes he thinks you're crazy but underneath that crazy looking
recommendation sits a lot of lessons learned due to the issues manifesting
in the language.
It's obvious to anyone that the current situation is not ideal and needs
fixing, I do not dispute this but I feel the current push towards new
features yields a less desirable result than our previous work arounds did.
Even if the current state is transient - but we do know its transient state
and so we should consider that in the kind of people we make recommendations
too.
>
> > 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.
yes, the alternatives I propose are hacks and work arounds and they suck -
yet they are almost at the same level I feel as the where param classes are
today they too are fraught with hacks and work arounds.
They are the right direction but they're still getting there. Thus
recommending
to all rather than say the more early adopter crowd in the community like
myself isn't the right hting to do right now I feel.
>
> > > 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.
I recall the thread and without going back to it now and reading it
I think the overall feeling of those who responded were that it was
the right thing to do. I often find myself thinking I wonder why
that never got done.
> 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.
Can we yet actually describe without getting bogged down in syntax
how we think scoping should work?
If we can get a clear description of what the various interactions
should be we could later deal with the syntax of it, I find throwing in
example syntax early on just leads the conversation down the wrong
direction
Has anyone here taken any part in how languages like Python or PHP etc
get designed? I'd say ruby but that process is very inaccessible. There
might be some process that works in other communities we can study for
hints?
--
R.I.Pienaar
--
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.
