The current management of puppet modules could do with some changes.
Rather than point out the things I dislike I will just outline my vision of how I see it all working.
- displays module metadata only. No actual module storage.
- Each listed module is just a link off to a code hosting site of choice (github, bitbucket etc)
- PMT reads meta data from forge and grabs module from appropriate code hosting site (wget?)
- PMT consumes forge API for updating module metadata etc
- re-introduce PMT support for specifying the forge address (for private forges)
- librarian-puppet becomes a face so that modules can be managed singularly or on mass.
-
- puppet module install vs puppet modules install
Private forges should be very easy then as the metadata can just point to private github/bitbucket repos easily.
What I mean here is that there is currently no real way of telling the maturity/stability level of a module
short of reading code, commit logs, and trying it out for yourself.
The forge is marketed as having >500 moudles but how many of these are really useable, up to date
and make use of current best practises ?
This is not a problem unique to Puppet modules. Drupal modules, community supplied OS system packages etc all share the same issues.
Some ideas around development flow/patterns.
- tag releases with SEMVER style tags.
- Forge only points to latest stable tag - not master/head or beta
- tag that states a module complies to guidelines
- tag that states a module has been accepted by >n community members
- tag that shows a module has been 'endorsed' by Puppetlabs*