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 puppet-dev+unsubscr...@googlegroups.com. 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.
