On 2013-28-08 16:27, Trevor Vaughan wrote:
Ack...I'm going to vote for keeping the autoloader.
Though it may be more inefficient, it is quite useful.
I have noticed that it seems to want to try to load *everything* though.
Restricting that to just .pp files where they are expected, loading ruby
files where they are expected, and ignoring anything that looks hidden
(.) or tempfiled (~) would be nice. This may have been fixed in 3.X, but
I know it causes me grief once in a while with the 2.X series.
Perhaps a Java-style middle ground?
1. Autoloading changes to work with declared load spaces first but can
be enabled to use global autoloading in your module path.
# New Loading Style (default)
autoloading = explicit
# Current Loading Style
autoloading = auto
2. Manifests can now use a more explicit syntax.
# Autoload all materials under the default module path for the given
module.
# This example loads the stdlib....
load 'stdlib'
# Autoload a distinct path outside of the module path
# You can, of course, do this on a site-wide basis now, but it would
be nice to have the flexibility to do it on a module basis.
load '/opt/great_stuff/foo'
# Load a specific file
load '/opt/good_stuff/bar.pp'
# What about custom functions, facts, and types?
# Not sure about this....
load '/opt/stuff/baz/lib'
I'm not entirely convinced that this is better than what we have now,
but it's certainly more flexible.
I'm also not 100% sold on the performance gains since I think that many
people will simply stick with the autoloader or autoload as much as is
convenient. I'm saying this due to the amount of Java/Ruby code that
I've seen that simply load the top level classpath and don't bother
picking and choosing exactly what sub-classes to load for efficiency.
You would have to figure out how to work this with an ENC as well.
Thanks,
Java import is a symbolic name import only. It is simply there to inform
the loader how to resolve a short name to a fully qualified name. The
search is then made using a class loader hierarchy.
Also see my other post with a proposal.
Will read your proposal more detailed as well...
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
