This is the best idea I've heard. Certain puppet types intend to provide an abstraction. This abstraction only works for native package providers in this case because anything else requires the user to make an informed decision. I think having all other package providers be separate types is just fine - package_gem or gem or whatever route you want to go is fine.
It seems this might be the only sane and agreeable solution to a problem people have fought for years. Keep the current providers in the package type (but deprecate) and create the new providers. We have a great opportunity to do this with Puppet 4 coming up. On Tuesday, October 7, 2014 9:10:11 PM UTC-5, Daniele Sluijters wrote: > > Separate types undoes basically what "package" now tries to make as > transparent as possible. I guess a case could be made to have "package" > only deal with the OS native package provider and have separate types and > providers for "secondary" packages like gem, wheel/egg/whatever etc. > > On Tuesday, 7 October 2014 12:39:13 UTC-7, Trevor Vaughan wrote: >> >> I'm still a fan of separate types. >> >> Just put a nail in the coffin once and for all since this is really the >> only type which tries to get fancy. >> >> Trevor >> >> On Tue, Oct 7, 2014 at 3:27 PM, John Bollinger <john.bo...@stjude.org> >> wrote: >> >>> >>> >>> On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker wrote: >>>> >>>> Sorry to resurrect an old thread, but this came to my attention again >>>> today. >>>> >>>> On Fri, Mar 14, 2014 at 6:20 AM, John Bollinger <john.bo...@stjude.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor Vaughan wrote: >>>>>> >>>>>> SecondaryPackage wouldn't fix it if you wanted to install using pip >>>>>> and gem on the same system. >>>>>> >>>>>> >>>>> >>>>> I see I should have devoted more text to my last statement: "The trick >>>>> here would be that the provider(s) must not be based on package type, so >>>>> that the package type could be used as part of a composite name." If the >>>>> type's name were a composite of type (gem, pip, etc.) and name within >>>>> that >>>>> type, then it very well could support different package types all in one >>>>> resource type. I suppose the individual package types could be features. >>>>> >>>>> Whereas such an approach cannot work for Package, it would be eminently >>>>> workable for a unified SecondaryPackage type. >>>>> >>>>> Putting it all in one type might make it a bit easier to convert >>>>> existing manifests, and it would give users a single place to look for >>>>> support for this sort of thing. On the other hand, the provider(s) would >>>>> have to support multiple (secondary) package types. It's a trade-off >>>>> between what aspects must be complicated and what parts can be simple. >>>>> >>>>> >>>> I think there might be a much simpler solution to the entire thing. I >>>> noticed that all of the error messages that I've seen about this are about >>>> being unable to alias. What seems to be happening is that since the "name" >>>> parameter of a package resource is the namevar, the system is >>>> automatically >>>> creating an alias for the package resource using the name. That means that >>>> we have both a Package[title] reference and a Package[name] reference. The >>>> same thing occurred in the comment that was recently added to the ticket >>>> about the tidy type. >>>> >>>> So here is my proposal: just remove the automatic aliasing. That means >>>> that the only way to reference a resource is via the title or an explicit >>>> alias. I tried this out on a VM by simply commenting out one line ( >>>> https://github.com/puppetlabs/puppet/blob/master/ >>>> lib/puppet/resource/catalog.rb#L90) and it seemed to work wonders. >>>> >>>> Why not just go with that change? Am I missing something? >>>> >>> >>> >>> The main issue is *name* (not necessarily title or alias) collisions. >>> If you want to manage an RPM named 'ntp' and also a gem named 'ntp' on the >>> same system then you are hosed. The two resources have the same unique >>> identifier ('ntp') which you pretty much have to use to map correctly to >>> the physical resource. If you give up on requiring uniqueness of >>> resources' natural unique identifiers then you throw in the towel >>> altogether on avoiding duplicate resources. >>> >>> The two names in my example actually live in different namespaces, but >>> those namespaces map to resource providers, which traditionally are not >>> specified in manifests nor known during catalog building, except for >>> packages that are expected or known in advance to be supported by a >>> "secondary" package provider. If this is a problem that's going to be >>> solved then I still like the SecondaryPackage resource type for that task, >>> or perhaps even separate Gem, etc. types. >>> >>> >>> John >>> >>> -- >>> 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+...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/90cc269a-13c4-4736-99a8-c3c81bd94d1e%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/puppet-dev/90cc269a-13c4-4736-99a8-c3c81bd94d1e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvau...@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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/086610c0-34e4-46ec-9c86-5e9352fd674a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
