Puppet users - Sep 2010 - Proposal to remove redundant info in source => parameters

[cross-posting as I''d like to know whether my intuition about this
being the most common case is correct]


class foo {

  file { "/etc/foo.conf":
    source => "puppet:///modules/foo/foo.conf",
  }

}

For me, every single one of my source specifications refers to a file
inside the current module. My intuition is that this is the most
common case outside my own deployment, so why don''t we optimize for
it?

class foo {

  file { "/etc/foo.conf":
    source => "foo.conf",
  }

}

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.



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <nigelk@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"),

Puppet would look in $templatedir/foo.erb which is
/var/lib/puppet/template/foo.erb, rather than foo module templates
directory.

If we make this change for files we should have both behave the same.

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <nan@puppetlabs.com>
wrote:
> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <nigelk@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"),
>
> Puppet would look in $templatedir/foo.erb which is
> /var/lib/puppet/template/foo.erb, rather than foo module templates
> directory.
>
> If we make this change for files we should have both behave the same.
Well that''s a function, which does behave differently anyway.

I have a similar proposal for the file function to behave exactly like
the template function.

I''d be reasonably happy to reduce my proposal to require the
modulename, but I still think it''s redundant info in the majority of
cases, but I guess the $module_name variable mitigates this somewhat.


>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <nan@puppetlabs.com>
wrote:
> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten <nigelk@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?

>
> Puppet would look in $templatedir/foo.erb which is
> /var/lib/puppet/template/foo.erb, rather than foo module templates
> directory.
>
> If we make this change for files we should have both behave the same.
>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 25, 2010, at 10:02 AM, Nigel Kersten wrote:
> On Fri, Sep 24, 2010 at 12:34 PM, Nan Liu <nan@puppetlabs.com> wrote:
>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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".

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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 <nan@puppetlabs.com>
wrote:
>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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
<nan@puppetlabs.com> wrote:
>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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"?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 10:27 AM, Patrick <kc7zzv@gmail.com>
wrote:
>
> On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
>
>> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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
<nan@puppetlabs.com> wrote:
>>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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
<nan@puppetlabs.com> wrote:
>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 2:22 PM, Luke Kanies <luke@puppetlabs.com>
wrote:
> On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
>
>> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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
<nan@puppetlabs.com> wrote:
>>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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.
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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 10:33 AM, Nigel Kersten
<nigel@explanatorygap.net>wrote:
> On Sat, Sep 25, 2010 at 10:27 AM, Patrick <kc7zzv@gmail.com> wrote:
> >
> > On Sep 25, 2010, at 10:23 AM, Nigel Kersten wrote:
> >
> >> On Sat, Sep 25, 2010 at 10:10 AM, Patrick <kc7zzv@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
<nan@puppetlabs.com> wrote:
> >>>>> On Fri, Sep 24, 2010 at 11:20 AM, Nigel Kersten
<nigelk@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi,

It looks like I missed your original e-mail to puppet-dev.

On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
> [cross-posting as I''d like to know whether my intuition about this
> being the most common case is correct]
> 
> 
> class foo {
> 
>   file { "/etc/foo.conf":
>     source => "puppet:///modules/foo/foo.conf",
>   }
> 
> }
> 
> For me, every single one of my source specifications refers to a file
> inside the current module. My intuition is that this is the most
> common case outside my own deployment, so why don''t we optimize
for
> it?
> 
> class foo {
> 
>   file { "/etc/foo.conf":
>     source => "foo.conf",
>   }
> 
> }
> 
> 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.
My issue with your proposal is that at first glance it will look like a
local copy (which should require an absolute path) and not a remote
copy. This certainly violate the least surprise paradigm for new users.

What about a new URI scheme (ie module) which would do the same:

class foo {
   file { "/etc/foo.conf":
     source => "module://foo.conf",
   } 
 }

-- 
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Sep 27, 2010 at 7:04 AM, Brice Figureau
<brice-puppet@daysofwonder.com> wrote:
> Hi,
>
> It looks like I missed your original e-mail to puppet-dev.
>
> On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
>> [cross-posting as I''d like to know whether my intuition about
this
>> being the most common case is correct]
>>
>>
>> class foo {
>>
>>   file { "/etc/foo.conf":
>>     source => "puppet:///modules/foo/foo.conf",
>>   }
>>
>> }
>>
>> For me, every single one of my source specifications refers to a file
>> inside the current module. My intuition is that this is the most
>> common case outside my own deployment, so why don''t we
optimize for
>> it?
>>
>> class foo {
>>
>>   file { "/etc/foo.conf":
>>     source => "foo.conf",
>>   }
>>
>> }
>>
>> 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.
>
> My issue with your proposal is that at first glance it will look like a
> local copy (which should require an absolute path) and not a remote
> copy. This certainly violate the least surprise paradigm for new users.
But you''re optimizing for an uncommon case...

Why doesn''t this concern matter for everything else that happens
server-side? template/file functions, imports, etc.

The client never sees the manifest, only the catalog. I am talking
about a local copy. Local to the server. :)

I''m talking about throwing out the current assumptions because I
don''t
think they''re aimed at the most common cases for Puppet, which are
client/server setups where your files primarily come from the modules
they are requested in.

> What about a new URI scheme (ie module) which would do the same:
>
> class foo {
>   file { "/etc/foo.conf":
>     source => "module://foo.conf",
>   }
>  }
It''s ugly and unnecessarily verbose in my opinion. How many different
protocols are we really going to add to Puppet?
>
> --
> Brice Figureau
> Follow the latest Puppet Community evolutions on www.planetpuppet.org!
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, 27 Sep 2010, Brice Figureau wrote:
> What about a new URI scheme (ie module) which would do the same:
> 
> class foo {
>    file { "/etc/foo.conf":
>      source => "module://foo.conf",
>    } 
>  }
If you go this way, please do not include "://" in the URI.  The
presence of "://" implies that the next thing after the
"://" will
be an "authority" part (defined in RFC 3986 section 3.2; e.g.
something like a hostname, or user@host:port, or the empty
string that represents an implied hostname).  RFC 3986 section 3
says ''When authority is not present, the path cannot begin with
two slash characters ("//").''

--apb (Alan Barrett)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 27, 2010, at 7:04 AM, Brice Figureau wrote:
> Hi,
> 
> It looks like I missed your original e-mail to puppet-dev.
> 
> On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
>> [cross-posting as I''d like to know whether my intuition about
this
>> being the most common case is correct]
>> 
>> 
>> class foo {
>> 
>>  file { "/etc/foo.conf":
>>    source => "puppet:///modules/foo/foo.conf",
>>  }
>> 
>> }
>> 
>> For me, every single one of my source specifications refers to a file
>> inside the current module. My intuition is that this is the most
>> common case outside my own deployment, so why don''t we
optimize for
>> it?
>> 
>> class foo {
>> 
>>  file { "/etc/foo.conf":
>>    source => "foo.conf",
>>  }
>> 
>> }
>> 
>> 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.
> 
> My issue with your proposal is that at first glance it will look like a
> local copy (which should require an absolute path) and not a remote
> copy. This certainly violate the least surprise paradigm for new users.
> 
> What about a new URI scheme (ie module) which would do the same:
> 
> class foo {
>   file { "/etc/foo.conf":
>     source => "module://foo.conf",
>   } 
> }
Another option is a new function:

class foo {
  file { "/etc/foo.conf":
    source => expand("foo.conf")
  }
}

Then all of the smarts could be in expand().

OTOH, I think it''s a bit think in terms of syntax.  Backticks? :)


-- 
Everything that is really great and inspiring is created by the
individual who can labor in freedom.  -- Albert Einstein
---------------------------------------------------------------------
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 27, 2010, at 10:08 PM, Luke Kanies wrote:
> On Sep 27, 2010, at 7:04 AM, Brice Figureau wrote:
> 
>> Hi,
>> 
>> It looks like I missed your original e-mail to puppet-dev.
>> 
>> On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
>>> [cross-posting as I''d like to know whether my intuition
about this
>>> being the most common case is correct]
>>> 
>>> 
>>> class foo {
>>> 
>>> file { "/etc/foo.conf":
>>>   source => "puppet:///modules/foo/foo.conf",
>>> }
>>> 
>>> }
>>> 
>>> For me, every single one of my source specifications refers to a
file
>>> inside the current module. My intuition is that this is the most
>>> common case outside my own deployment, so why don''t we
optimize for
>>> it?
>>> 
>>> class foo {
>>> 
>>> file { "/etc/foo.conf":
>>>   source => "foo.conf",
>>> }
>>> 
>>> }
>>> 
>>> 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.
>> 
>> My issue with your proposal is that at first glance it will look like a
>> local copy (which should require an absolute path) and not a remote
>> copy. This certainly violate the least surprise paradigm for new users.
>> 
>> What about a new URI scheme (ie module) which would do the same:
>> 
>> class foo {
>>  file { "/etc/foo.conf":
>>    source => "module://foo.conf",
>>  } 
>> }
> 
> Another option is a new function:
> 
> class foo {
>  file { "/etc/foo.conf":
>    source => expand("foo.conf")
>  }
> }
> 
> Then all of the smarts could be in expand().
> 
> OTOH, I think it''s a bit think in terms of syntax.  Backticks? :)
Single quotes are popular enough that I think backticks would be a nightmare.


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Please no backticks or other characters like "~", those of us who do
not have a U.S. keyboard layout have a hard time typing them (2-to-3
keys combinations in some cases).

On Sep 28, 7:33 am, Patrick <kc7...@gmail.com>
wrote:
> On Sep 27, 2010, at 10:08 PM, Luke Kanies wrote:
>
>
>
>
>
> > On Sep 27, 2010, at 7:04 AM, Brice Figureau wrote:
>
> >> Hi,
>
> >> It looks like I missed your original e-mail to puppet-dev.
>
> >> On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
> >>> [cross-posting as I''d like to know whether my
intuition about this
> >>> being the most common case is correct]
>
> >>> class foo {
>
> >>> file { "/etc/foo.conf":
> >>>   source => "puppet:///modules/foo/foo.conf",
> >>> }
>
> >>> }
>
> >>> For me, every single one of my source specifications refers to
a file
> >>> inside the current module. My intuition is that this is the
most
> >>> common case outside my own deployment, so why don''t
we optimize for
> >>> it?
>
> >>> class foo {
>
> >>> file { "/etc/foo.conf":
> >>>   source => "foo.conf",
> >>> }
>
> >>> }
>
> >>> 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.
>
> >> My issue with your proposal is that at first glance it will look
like a
> >> local copy (which should require an absolute path) and not a
remote
> >> copy. This certainly violate the least surprise paradigm for new
users.
>
> >> What about a new URI scheme (ie module) which would do the same:
>
> >> class foo {
> >>  file { "/etc/foo.conf":
> >>    source => "module://foo.conf",
> >>  }
> >> }
>
> > Another option is a new function:
>
> > class foo {
> >  file { "/etc/foo.conf":
> >    source => expand("foo.conf")
> >  }
> > }
>
> > Then all of the smarts could be in expand().
>
> > OTOH, I think it''s a bit think in terms of syntax.
 Backticks? :)
>
> Single quotes are popular enough that I think backticks would be a
nightmare.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Sep 27, 2010 at 10:08 PM, Luke Kanies <luke@puppetlabs.com>
wrote:
> On Sep 27, 2010, at 7:04 AM, Brice Figureau wrote:
>
>> Hi,
>>
>> It looks like I missed your original e-mail to puppet-dev.
>>
>> On Fri, 2010-09-24 at 11:20 -0700, Nigel Kersten wrote:
>>> [cross-posting as I''d like to know whether my intuition
about this
>>> being the most common case is correct]
>>>
>>>
>>> class foo {
>>>
>>>  file { "/etc/foo.conf":
>>>    source => "puppet:///modules/foo/foo.conf",
>>>  }
>>>
>>> }
>>>
>>> For me, every single one of my source specifications refers to a
file
>>> inside the current module. My intuition is that this is the most
>>> common case outside my own deployment, so why don''t we
optimize for
>>> it?
>>>
>>> class foo {
>>>
>>>  file { "/etc/foo.conf":
>>>    source => "foo.conf",
>>>  }
>>>
>>> }
>>>
>>> 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.
>>
>> My issue with your proposal is that at first glance it will look like a
>> local copy (which should require an absolute path) and not a remote
>> copy. This certainly violate the least surprise paradigm for new users.
>>
>> What about a new URI scheme (ie module) which would do the same:
>>
>> class foo {
>>   file { "/etc/foo.conf":
>>     source => "module://foo.conf",
>>   }
>> }
>
> Another option is a new function:
>
> class foo {
>  file { "/etc/foo.conf":
>    source => expand("foo.conf")
>  }
> }
>
> Then all of the smarts could be in expand().
>
> OTOH, I think it''s a bit think in terms of syntax.  Backticks? :)
I think it''s too heavy and too tacked on.

After looking up a few of the major non-US keyboard layouts, I''m
really not sure ''~'' makes sense anymore. How do you people use
Unixes?
:)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, 2010-09-28 at 08:23 -0700, Nigel Kersten wrote:
> [heavilly snipped because answer OT]
> After looking up a few of the major non-US keyboard layouts, I''m
> really not sure ''~'' makes sense anymore. How do you
people use Unixes?
> :)
I dumped my azerty keyboard in favor of an US one as soon as I started
programming/admining :) 
Now I struggle to add accented vowels when I write in French :)
-- 
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Brice Figureau wrote:
> On Tue, 2010-09-28 at 08:23 -0700, Nigel Kersten wrote:
>> [heavilly snipped because answer OT]
>> After looking up a few of the major non-US keyboard layouts,
I''m
>> really not sure ''~'' makes sense anymore. How do you
people use Unixes?
>> :)
Is OSX Unix? :)
> 
> I dumped my azerty keyboard in favor of an US one as soon as I started
> programming/admining :) 
> Now I struggle to add accented vowels when I write in French :)
What will you do without your outrageous accent? Oh "write in
French"... :P

James

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Sep 28, 2010 at 9:06 AM, James Turnbull <james@puppetlabs.com>
wrote:
> Brice Figureau wrote:
>> On Tue, 2010-09-28 at 08:23 -0700, Nigel Kersten wrote:
>>> [heavilly snipped because answer OT]
>>> After looking up a few of the major non-US keyboard layouts,
I''m
>>> really not sure ''~'' makes sense anymore. How do
you people use Unixes?
>>> :)
>
> Is OSX Unix? :)
It is. They paid the money :)

>> I dumped my azerty keyboard in favor of an US one as soon as I started
>> programming/admining :)
>> Now I struggle to add accented vowels when I write in French :)
>
> What will you do without your outrageous accent? Oh "write in
French"... :P
He could get a Mac. :) accented vowels are trivial on OS X US keyboards.

So back on a serious note... Is this definitely a deal breaker ? I
really don''t want us to be US-centric...

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> So back on a serious note... Is this definitely a deal breaker ? I
> really don''t want us to be US-centric...
it wouldn''t be one for me and I still stick with sg keyboards.

~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyiQ70ACgkQbwltcAfKi390gQCgldW2Q7VIqUfv0SJ3kjZKEHRg
KsAAnionImj1J9Zl5sP1qoos5LHiDh++
=FnVe
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Am 28.09.2010 21:36, schrieb Peter Meier:
> it wouldn''t be one for me and I still stick with sg keyboards.
It is two keys on most European keyboard layouts. I think that it will be
ok for most *nix users. We are already used to it. ;-)

For me, it would be a real time saver. Two keys is much less than the same
use case requires me to type now.

Christian

-- 
Dipl.-Inf. Christian Kauhaus <>< · kc@gocept.com · systems
administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Sep 29, 2010 at 9:23 AM, Christian Kauhaus <kc@gocept.com>
wrote:
> Am 28.09.2010 21:36, schrieb Peter Meier:
>> it wouldn''t be one for me and I still stick with sg keyboards.
>
> It is two keys on most European keyboard layouts. I think that it will be
> ok for most *nix users. We are already used to it. ;-)
>
> For me, it would be a real time saver. Two keys is much less than the same
> use case requires me to type now.
Excellent. :)

I''ll put a feature request in today and re-post it to the list so
people can provide more detailed feedback where it''s easier to track.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Sep 29, 2010 at 9:38 AM, Nigel Kersten <nigelk@google.com>
wrote:
> On Wed, Sep 29, 2010 at 9:23 AM, Christian Kauhaus <kc@gocept.com>
wrote:
>> Am 28.09.2010 21:36, schrieb Peter Meier:
>>> it wouldn''t be one for me and I still stick with sg
keyboards.
>>
>> It is two keys on most European keyboard layouts. I think that it will
be
>> ok for most *nix users. We are already used to it. ;-)
>>
>> For me, it would be a real time saver. Two keys is much less than the
same
>> use case requires me to type now.
>
> Excellent. :)
>
> I''ll put a feature request in today and re-post it to the list so
> people can provide more detailed feedback where it''s easier to
track.
Posted: http://projects.puppetlabs.com/issues/4885





-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten <nigel@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.
> Where else could we use this? On import statements?
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"
> 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")

-- 
Jeff McCune
http://www.puppetlabs.com/

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten
> <nigel@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Sep 29, 2010 at 9:22 PM, Jeff McCune <jeff@puppetlabs.com>
wrote:
> On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten
<nigel@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.
>
>> Where else could we use this? On import statements?
>
> 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"
>
>> 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")
Please update the bug with this so it doesn''t fall through the tracks,
agreed on all counts.

http://projects.puppetlabs.com/issues/4885

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.