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"?
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.
>
> --
> 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.
>
>
--
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.
