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 puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
