On Saturday, February 1, 2014 7:48:53 AM UTC-6, bert hajee wrote: > > The discussion seems to go in the direction of not having a provider. >
I must have missed all that. > easy_type is by no means at all meant to stop using a provider. Actually, > it is by no means a total replacement for the Type and Provider pattern. > What it is, is an add-on module for people, less knowledgeable about Puppet > (and the intricacies of Types and providers) to have a custom type for an > easy kind of resource. > And as far as it goes, it looks like a good and useful tool, as long as its limits are understood. > Probably only on one kind of OS. > > I think that's an understatement. Inasmuch as the key methods are defined on the type, the module really supports only custom types with a single provider. That is to say, although additional providers could be written, it looks like easy_type would start to get in the way more than it helps for the second and subsequent provider. That's not necessarily a problem in any particular case, but it does make easy_type a special-purpose tool. > That said about the current discussion, what I like about the discussion, > is that we seem to all have the idea, it should be easier to make custom > types. While we disagree on (at least some) of the directions I took with > easy_type. Why not turn this into a discussion on what we would like to see > in an easy way to build a type. > > I'l start, but please join: > - A way to keep it close to people who know about the resource, but less > about Puppet > - Be able to easy abstract different OS-es and version (Like the current > provider > - Make it easier to call a set of standard available (and extendable) > validators > - Make it easier to call a set of standard available (and extendable) > mungers. > - Make it easy to gradually build the os command by stating a base part > and extending it if a property or a name is specified in the resource > definition. > > Absolute top of my list, ever since I first played with custom types: - Formal, complete, public documentation of the API Puppet provides to custom types and providers - Formal, complete, public documentation of the API Puppet expects custom types and providers to expose Nothing else even comes close. The guides PL provides around this area are helpful -- and more so now than they used to be -- but they are not an adequate substitute for *bona fide* API docs. Moreover, without good reference docs it's hard even to discuss what new features could benefit Puppet, because there is no shared understanding of what Puppet already has. 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/b5339852-5f31-4c0d-a31e-ea3d2c9676ac%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
