On 18.02.2013 15:28, Andy Parker wrote:
On Mon, Feb 18, 2013 at 6:14 AM, David Schmitt <da...@dasz.at <mailto:da...@dasz.at>> wrote:On 18.02.2013 12:52, Andy Parker wrote: I think publishing this on the forge would be a great idea. It does leave open the question of what we should be doing with the things that are already in core. It is a shame to have them rot and force everyone to download another module to get working ssh_authorized_key management. My plan for slimming down puppet was to pull out types and providers to put them on the forge and then bundle some back in during packaging so that we still had a "batteries included" puppet installation. We still need to figure out how to do that in a manner that "just works". Would it be enough to have a separate recommended modules package that installs default modules into a system location (/usr/share/puppet/modules) which is configured into the default module path? Now THAT is an interesting idea. Are you thinking that this would be a kind of bundle module that is just a list of dependencies, or would it be a puppet module that would be executed with puppet apply.
When you're saying "packaging," I'm thinking "put all the files from the forge into the deb/rpm." Feel free to put that into puppet-librarian or something like that, but the packages should be self-contained.
In some enterprises it is hard enough to get a package through The Process. It wouldn't do to have that package go around downloading Dangerous Stuff from the internet.
Also there should be the same API promise/semver stuff going on as with puppet core.
I don't think it would be quite this simple, though. This is because the puppet master is still not that great at loading in types and custom functions that rely on other code. Also I want to make it so that a user can install a newer version of the module and that one takes precedence. So if we were to do this we would need to: * Install into that known, common location * Add the lib directories of those modules to the $LOAD_PATH or update all of the ruby code in them to handle loading from a relative location * Ensure that puppet can handle selecting only the newest version of the module when it appears twice in the module path
Those problems already exist for "local" modules, so you want to solve that anyways. I usually to a local puppet agent plugin sync run to work around that. It's not pretty.
Best Regards, David -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
