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, Trevor On Tue, Aug 27, 2013 at 4:48 PM, Andy Parker <a...@puppetlabs.com> wrote: > On Tue, Aug 27, 2013 at 1:47 PM, Erik Dalén > <erik.gustav.da...@gmail.com>wrote: > >> On 27 August 2013 20:44, Andy Parker <a...@puppetlabs.com> wrote: >> >>> On Tue, Aug 27, 2013 at 10:21 AM, Jeff McCune <j...@puppetlabs.com>wrote: >>> >>>> If by "load everything" we're talking about something equivalent to >>>> include <modulepath>/**/*.pp then that's silly and should be avoided. It >>>> would be a big step in the wrong direction, taking away control from the >>>> end user rather than giving them more control over the system. >>>> >>>> Markus suggested explicit loading. Explicit loading is a much better >>>> approach. It's more efficient, it's well understood by everyone, and it >>>> gives the end user explicit control over the behavior of the system. It >>>> comes at the cost of a bigger impact to all of our users, but that's OK. >>>> Puppet 4 shouldn't be that far off and we likely can make this behavior >>>> gated on a feature flag for Puppet 3. >>>> >>>> >>> Explicit loading would be another option. That would say that we get rid >>> of the manifest autoloader and require that everyone uses the import >>> keyword. That might be a good middle ground. >>> >>> >> In that case it would be good if include/require was >> import+include/require so you don't constantly have to type both. Then >> import would only really be needed when using defined types. >> >> > And....we are back at the autoloader :) > > >> -- >> Erik Dalén >> >> -- >> 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. >> > > > > -- > Andrew Parker > a...@puppetlabs.com > Freenode: zaphod42 > Twitter: @aparker42 > Software Developer > > *Join us at PuppetConf 2014, September 23-24 in San Francisco* > > -- > 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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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.
