----- "Jeff McCune" <j...@puppetlabs.com> wrote:
> On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten
> <ni...@explanatorygap.net> wrote:
> > What implications of introducing a new syntactical element are
> there?
>
> Yet another inconsistency and confusion for newbies.
>
> With that said, I think the benefits _far_ outweigh the drawbacks.
> Especially since it brings consistency to the behavior of file()
> template() and source.
agree, we now have $module_name and friends which means we could achieve
similar via a define but this syntax is much better
> > Where else could we use this? On import statements?
file() and template() should also support the array search order syntax same as
source => does if we really want to get consistent behavior
>
> Any function that needs to read data from the file system on the
> master.
>
> I'm looking at you, extlookup() ...
>
> Today I wrote a function called getconf() which is little more than
>
> Puppet::Parser::Functions.newfunction(:getconf, :type => :rvalue) do
> |args|
> Puppet.settings[args[0]]
> end
>
> The motivation was to store extlookup data inside of confdir which is
> usually under version control and at different file system paths for
> development, testing, and production.
>
> $confdir = getconf("confdir")
> $extlookup_datadir = "${confdir}/extdata"
arent all the settings now available as variables?
% echo 'notice($settings::confdir)'|puppet
notice: Scope(Class[main]): /home/rip/.puppet
It's easy to gripe about abusing global variables the way extlookup does, there
are very few options available to parser functions to do the right thing though.
I've filed a few enhancement requests around these but it seems the specific
thing about config files i missed, it would be really nice if a plugin like
extlookup can somehow hook into the main config file and add environment aware
config options that we can access, that would have made the extlookup code/use
a hell of alot less hacky
> > import "foo.pp" already looks in the current working directory, but
> is
> > there any point trying to add this throughout the language so you
> can
> > do:
> >
> > # modules/foo/manifests/a/b/c/d/contrived.pp
> > import "~/clean.pp"
> >
> > and it resolves to modules/foo/manifests/clean.pp ?
>
> I think no matter what the path expansion logic should be generalized
> into some utility method so types, providers, functions, report
> processors, and whatever else we cook up can take advantage of this.
>
> A quick win could be to add an path_to() function to the language
> which should give us the desired behavior for free.
>
> import path_to("~/clean.pp")
we'd need to think about defines quite carefully,
define somemodule::filecopier(...) {
file{$name:
source => "~/${name}"
}
}
someothermodule::filecopier{"foo": }
here the ~/${name} need to expand to someothermodule/files/${name} not
somemodule/files/${name}
--
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.
