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 <[email protected]> wrote: > On Tue, Aug 27, 2013 at 1:47 PM, Erik Dalén > <[email protected]>wrote: > >> On 27 August 2013 20:44, Andy Parker <[email protected]> wrote: >> >>> On Tue, Aug 27, 2013 at 10:21 AM, Jeff McCune <[email protected]>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 [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. >> > > > > -- > Andrew Parker > [email protected] > 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 [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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- 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 [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.
