On Sat, Sep 25, 2010 at 2:22 PM, Luke Kanies <[email protected]> wrote:
> On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
>
>> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <[email protected]> wrote:
>>>
>>> On Sep 25, 2010, at 10:02 AM, Nigel Kersten wrote:
>>>
>>>> On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <[email protected]> wrote:
>>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <[email protected]> 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.
I thought about this for a while and even started to mock something
up, but it's kind of ugly.
There's something gorgeously attractive about being able to move to:
file { "/etc/sshd_config":
source => "~/sshd_config",
}
What implications of introducing a new syntactical element are there?
Where else could we use this? On import statements?
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 ?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
