On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote: > On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7...@gmail.com> wrote: >> >> On Sep 25, 2010, at 10:02 AM, Nigel Kersten wrote: >> >>> On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <n...@puppetlabs.com> wrote: >>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <nig...@google.com> wrote: >>>>> eg the proposal is that if you don't specify the protocol, server >>>>> address, modules prefix, module name, it is assumed you are referring >>>>> to a file path relative to the 'files' subdirectory of the current >>>>> module. >>>>> >>>>> If you wish to fully specify the source URI, you're free to do so. >>>> >>>> Since we can determine module_name in 2.6, I agree with this change. >>>> But we should update template behavior so it's the same as file. >>>> Currently for templates: >>>> >>>> content => template("foo.erb"), >>> >>> Ah I missed addressing this point. >>> >>> I don't think we can do this and still have backwards compatibility. >>> >>> How do you tell whether 'foo/bar.erb' refers to 'foo' the module or a >>> subdirectory 'foo' in the current module? Which should take >>> precedence? How do we throw a deprecation warning? >>> >>> I don't think we can feasibly forbid references to templates outside >>> the current module. That would have a significant effect upon our >>> ability to share modules. >>> >>> With the benefit of hindsight, we should possibly have made the source >>> parameter, file function and template function consistent... >>> >>> Can we get there from here? >> >> What about instead defining something uncommon to be "module root". >> Something like, as a random example, "~/". Then the syntax goes from >> "file:///modules/$modulename/file" to "~/file". > > I'm normally really reluctant to add more special characters to the > syntax, as I feel like we're way too busy as it stands, but I really > do quite like this idea, using normal *nix syntax for your home vs > other users... > > Let me incorporate your suggestion as I think adding syntax allows us > to make all three consistent. > > modules/$module_name/files/foo > file { source => "~/foo" } > > File (source) from another module 'bar': > file { source => "~bar/foo" } > > modules/$module_name/templates/foo.erb > template("~/foo.erb") > > modules/bar/templates/foo.erb: > template("~bar/foo.erb") > > modules/$module_name/files/foo > file("~/foo") > > modules/bar/files/foo > file("~bar/foo") > > > All of this *only* applies if you are within a module. > We don't deprecate the puppet:// or file:// syntax > Do we deprecate the existing template function syntax? > If not, do we add the existing template function syntax to the file > function for consistency? > We don't support setting the server, or access to static mount points. > If you want those, use the puppet:// syntax. > > This feels good. We're optimizing for the two most common cases, > without removing the most flexible syntax.
I agree, this is a good option. The only other one I thought of was introducing a 'module_path' function or something similar to do the path expansion. -- Hegel was right when he said that we learn from history that man can never learn anything from history. -- George Bernard Shaw --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- 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.