Hi Martin,
On Sun, Feb 5, 2017 at 2:35 PM, Martin Alfke <tux...@gmail.com> wrote:
> It seems to me as if you are “hiding” some things which are hard to
> understand - similar to mk_resource_methods which is useful when following
> some silent assumptions.
>
My big hope is that we can do away with all that internal machinery and
replace it with a very simple interface between types and providers
(roughly: look up existing resources and change resources, what David has
as set and get in his proposal)
> Think of something like the following (yes, I know, “type” is already a
> reserved word):
>
> type my_module::my_file (
> Enum['file', 'absent' ] $ensure,
> Stdlib::Absolute_path $path = $title,
> String $owner,
> ){
> def create {
> exec { "create file ${path}":
> command => "touch ${path}",
> path => '/usr/bin:/bin',
> creates => $path,
> }
> }
> def destroy {
> file { $path:
> ensure => absent,
> }
> }
> property owner {
> exec { "chown ${owner} on ${path}":
> command => "chown ${owner} ${path}",
> path => '/bin:/usr/bin',
> unless => '',
> }
> }
> }
>
> (I know that exec should not be used in this way.)
>
I think it's totally reasonable for people to write Puppet code that acts
like a type/provider; but that's possible today as you could turn the above
code into a defined type.
To me, the point of the type/provider mechanism is to allow extending what
Puppet can manage beyond what's easily accessible via Puppet. I think that
simplification here means that the provider is exposed to a larger-scale
change, i.e. is told to enforce a particular resource. Looking, for
example, at this systemd provider
<https://github.com/puppetlabs/libral/blob/master/data/providers/systemd.prov>
or this dnf provider
<https://github.com/puppetlabs/libral/blob/master/data/providers/dnf.prov>
makes me think that breaking change into small pieces (per property)
actually makes it harder to write providers, not easier. There's clearly
room for adding some language-specific conveniences, but even without that
I think the code is pretty straightforward.
People with ruby experience will not find types and providers difficult (in
> the way they are done today).
>
> But Puppet was originally written for Ops people who don’t like scripting
> or coding.
>
Yes, this is a really thorny one - my hunch is that writing types and
providers will always be an advanced topic, and it's therefore reasonable
to assume some familiarity with scripting.
David
--
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/CAHN%2BA%2BWPfb1q2859uz9xwazDb-0%3DwQ8TnngD-fxoP-90hu5XUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
