On Sat, Sep 25, 2010 at 10:33 AM, Nigel Kersten <ni...@explanatorygap.net>wrote:
> On Sat, Sep 25, 2010 at 10:27 AM, Patrick <kc7...@gmail.com> wrote:
> >
> > 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.
> >
> > Here's something to think about. Would it be worth the effort to allow
> "file://server.com/~/file <http://server.com/%7E/file>"?
>
> I don't think we mention file:// in the docs at all... I'd always been
> under the impression that we supported "puppet://" for server-side
> URIs and anything else was a local filesystem path.
>
> Testing shows we do support file:///tmp/foo just like /tmp/foo. Huh.
>
> Back to your question... I don't think so, but others may have a
> different opinion.
>
>
That was a typo. I meant
Would it be worth the effort to allow "puppet://server.cxm/~/file"? This
allows you to specify the server, but not give the full path.
--
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.
