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. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/3c52ca61-15b1-48e7-a694-c3fafd70b11c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
