On Mon, Jan 13, 2014 at 6:56 PM, Nan Liu <nan....@gmail.com> wrote: > It's great the core type/provider is getting a serious review. > > On Mon, Jan 13, 2014 at 4:20 PM, Andy Parker <a...@puppetlabs.com> wrote: > >> On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg <k...@puppetlabs.com>wrote: >> > Even later to the party, but I agree :) The alternative of a contrib >>> directory could muddy the waters so that there were 3 locations a given >>> type/provider could land (core/contrib/module), when the current 2 >>> locations (core/module) suffice. Easy to imagine extra bike-shedding on >>> where something lands and/or the contrib directory becoming a failed >>> experiment wasteland. >>> >>> >> Ok, so the initial idea of keeping a "contrib" inside the puppet codebase >> for some things under active development seems to be a losing one. What >> about the trimmed down idea of having it be a staging ground for pulling >> things out (in which case "contrib" is a terrible name for it)? >> > > The less the better, since this could get pretty confusing to > troubleshoot. Maybe a mechanism which collapse the providers to avoid a > large module sprawl. At minimum a tool to track everything: > > puppet resource_types > - package core > - service core > - database /etc/puppetlabs/puppet/modules/mysql > ... > > puppet resource_providers package > - package: > |- apt /etc/puppetlabs/puppet/modules/apt/ v1.0 > |- gem /usr/share/puppet/modules/gem v1.0 > ... > > That brings up a good point. In the perl world you have corelist ( http://stackoverflow.com/questions/2049735/how-can-i-tell-if-a-perl-module-is-core-or-part-of-the-standard-install), which becomes invaluable for writing portable CPAN modules. It helps answer the question, which gets harder and harder as time goes on, of "what version of Foo was shipped in core version X?"
> However, one question I have about shipping modules with puppet as >>> discussed in this thread: are people thinking this means modules >>> pre-installed in /usr/share/puppet/modules, or that the packaging step >>> would merge/patch the tier2 modules into puppet proper? >>> >>> >> I'm interested in this as well. >> > > Maybe merging would be better, at least to force detection of colliding > providers (you can't install two versions of the yum provider). > I'm not clear on what you mean. Does installing two versions of the yum provider not work, or are you saying that this would be a desirable outcome? > > >> If the former, is that overly disruptive to sites that specify >>> modulepath? If the latter, does that complicate sites that want to upgrade >>> one of the packaged-in modules using pmt? I haven't thought this through, >>> so there may be a perfectly simple answer. >>> >> > Installing to /usr/share would be a pain for things like vagrant (which > assumes a single puppet module path). I can see other issues with testing > in vagrant, and there would be quite an increase in .fixture.yml just to do > something basic. > > For puppet upgrades there's no assumption that modules are compatible and > I think handling upgrades of type/provider modules would be similar process > (Puppetfile/librarian-puppet or r10k). > > Nan > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CACqVBqCNGvA8AuB_%3DFZ_HXpQPAs08TnbgXA%3D%2BtBzt3aQMPxckQ%40mail.gmail.com > . > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXskpfaOb0h8%2B3ruzspM59oJ1W32LQOSmBmoFppvckHCnA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
