Collection of refactors

[Phil-Friderici]

Based on PR #1 this PR collects the refactors we want \o/

[Phil-Friderici]

After merging this, we should create a new major version :)

[anders-larsson]

Looks OK to me.

I have a general question though. What's the point of wrapping all the resource type instead of calling the resource type directory? Is it the extra input validation? Wouldn't the source complain regardless if input is invalid?

[Phil-Friderici]

I have a general question though. What's the point of wrapping all the resource type instead of calling the resource type directory? Is it the extra input validation? Wouldn't the source complain regardless if input is invalid?

I am not sure I did understand you correctly.
I guess the hashes in init.pp are usefull to be able to use hiera and it's merge functionality.

[anders-larsson]

I have a general question though. What's the point of wrapping all the resource type instead of calling the resource type directory? Is it the extra input validation? Wouldn't the source complain regardless if input is invalid?

I am not sure I did understand you correctly. I guess the hashes in init.pp are usefull to be able to use hiera and it's merge functionality.

I'm speaking about the wrapper defines for the resources. Like exec.pp, package.pp. E.g. Why do we have defines for reach resource instead of using create_resources($hash).

[Phil-Friderici]

Next guess, this was needed in the old times.
What you would like is available in one module from Voxpupuli:
https://github.com/voxpupuli/puppet-system
Instead of changing ours and migrating our hiera data, I would recommend to switch the modules.

[anders-larsson]

Looks like it has been archived? Do we know why?

[Phil-Friderici]

Looks like it has been archived? Do we know why?

Missed that :( But I guess there are a lot more available giving this kind of functionality.
We could also add it to ours if you prefer.

[Phil-Friderici]

Released as v2.0.0-forked

[Phil-Friderici]

Looks like it has been archived? Do we know why?

Maybe because stdlib::manage is good enough ?

[anders-larsson]

Hm. Maybe that's something that should be used instead. Indeed! Guess we'll still need this one for now but maybe we should move towards stdlib::manage.