[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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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?

--
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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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.

--
never learn anything from history.      -- George Bernard Shaw

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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
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.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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.

It's ugly and unnecessarily verbose in my opinion. How many different
protocols are we really going to add to Puppet?

--
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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
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).

--
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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

Is OSX Unix? :)

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

It is. They paid the money :)

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

it wouldn't be one for me and I still stick with sg keyboards.

~pete

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*******· systems administraton
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · gemany 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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

Yet another inconsistency and confusion for newbies.

Especially since it brings consistency to the behavior of file()
template() and source.

Any function that needs to read data from the file system on the master.

I'm looking at you, extlookup() ...

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"

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*******.
To unsubscribe from this group, send email to puppet-users+unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppet-users?hl=en.

agree, we now have $module_name and friends which means we could achieve smilar via a define but this syntax is much better

file() and template() should also support the array search order syntax sae as source => does if we really want to get consistent behavior

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, here are very few options available to parser functions to do the right thng though.

I've filed a few enhancement requests around these but it seems the specifc thing about config files i missed, it would be really nice if a plugin lke extlookup can somehow hook into the main config file and add environmen aware config options that we can access, that would have made the extlookp code/use a hell of alot less hacky

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 sommodule/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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.

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*******.
To unsubscribe from this group, send email to puppet-users unsubscribe*******.
For more options, visit this group at  http://groups.google.com/group/puppe-users?hl=en.