Publish to the Puppet Forge

[ryanycoleman]

I'd like to nominate this module for inclusion in the Puppet Approved program on the Puppet Forge but don't see this module published. Hiera backends can be published to the Puppet Forge like any plugin in a module.

All you need to do is add proper metadata to the root directory, run puppet module build using a recent version of Puppet, and publish the tarball on the Forge. More complete documentation is available.

I'm here to help if you need it and hope to see the module on Forge soon.

[gtmtech]

How about something like this @ryanycoleman ? I'm slightly confused on the dependencies section as puppet "modules" seem built more to have puppet code inside them, rather than this which is really a gem that needs installing. I'm not sure how installing this via e.g. librarian-puppet would ensure that the gem gets installed... could you clarify? Thanks

{
  "name": "hiera-eyaml",
  "version": "2.0.3",
  "author": "Tom Poulton",
  "license": "Licensed under (MIT)",
  "summary": "A plugin module for hiera allowing secure encrypted hiera data values using different encryption types",
  "source": "https://github.com/TomPoulton/hiera-eyaml",
  "project_page": "https://github.com/TomPoulton/hiera-eyaml",
  "issues_url": "https://github.com/TomPoulton/hiera-eyaml/issues",
  "tags": ["hiera", "eyaml", "encryption", "passwords"],
  "operatingsystem_support": [
    {
    "operatingsystem":"RedHat",
    "operatingsystemrelease":[ "5.0", "6.0" ]
    },
    {
    "operatingsystem": "Ubuntu",
    "operatingsystemrelease": [ "12.04", "12.10", "13.04", "13.10", "14.04", "14.10" ]
    }
   ],
  "dependencies": [
  ]
}

[ryanycoleman]

@gtmtech You're right that dependencies metadata is meant for other Puppet modules from the Forge. Those modules could provide classes, resources or other plug-ins to Puppet. If hiera-eyaml has no dependencies on other modules, you can leave that field blank.

If you expect a particular Puppet version to function, you can express this in metadata as well. The information is displayed on module pages and on Forge search filters.

There isn't a simple way to bring in non-Puppet dependencies for plug-ins like ruby gems. The standard practice is to document them early in the README as a minimum. Often, a module like this will include a class that will install the necessary gems as a convenience to the user.

The metadata looks great except for two things. I'm not sure how Forge will handle the ()'s around the project_page url. Also, you're missing a comma at the ] before dependencies. You can pass the metadata through any json linter or through a module metadata linter like this one made by a community member.

Thanks for doing this!

[TomPoulton]

Hi Ryan

It was good to meet you at puppet conf

If this is installed as a puppet module will the eyaml cli tool still work? hiera-eyaml is a backend for hiera but it also has a command line tool (thanks to Geoff and Simon)

Thanks for knocking up the metadata Geoff

Tom

On Wed, Oct 8, 2014 at 11:35 AM, Ryan Coleman notifications@github.com wrote:

@gtmtech https://github.com/gtmtech You're right that dependencies metadata is meant for other Puppet modules from the Forge. Those modules could provide classes, resources or other plug-ins to Puppet. If hiera-eyaml has no dependencies on other modules, you can leave that field blank.

If you expect a particular Puppet version to function, you can express this in metadata https://github.com/puppetlabs/puppetlabs-ntp/blob/master/metadata.json#L76 as well. The information is displayed on module pages and on Forge search filters.

There isn't a simple way to bring in non-Puppet dependencies for plug-ins like ruby gems. The standard practice is to document them early in the README as a minimum. Often, a module like this will include a class that will install the necessary gems as a convenience to the user.

The metadata looks great except for two things. I'm not sure how Forge will handle the ()'s around the project_page url. Also, you're missing a comma at the ] before dependencies. You can pass the metadata through any json linter http://jsonlint.com/ or through a module metadata linter like this one https://github.com/nibalizer/metadata-json-lint made by a community member.

Thanks for doing this!

— Reply to this email directly or view it on GitHub https://github.com/TomPoulton/hiera-eyaml/issues/108#issuecomment-58386915 .

[ryanycoleman]

@TomPoulton, it was good to meet you as well. Sorry it was so brief.

Crap. I forgot about the CLI executable. Though Puppet will load the hiera backend from the modulepath, it won't do anything with the bin/ directory. I tried searching for a way to do this if the tool were exposed as a Puppet Face or a Puppet Subcommand but couldn't figure it out. I'll ping a few others at PL for help.

[gtmtech]

I've updated the metadata above - minus the () and plus the , as indicated. Lets wait on what @ryanycoleman comes back with from PL, and see what to do

[iamteedoh]

This is good news. I am looking forward to this inclusion :+1:

[ryanycoleman]

I thought I had already replied to this thread but apparently not. Sorry about that.

Unfortunately, today's Puppet will only load CLI built through Faces in modules. So, if you shipped hiera-eyaml as a module on the Puppet Forge, the CLI will not function but will not harm anything. The heira backend will be loaded. I'm not certain how the backend will behave if it's in both the module path and gem path. For convenience and discovery of being on Forge, I propose this route:

• ship the CLI as a standalone ruby gem
• ship the hiera backend as a Forge module
• include a class in the module which installs the cli from ruby gems (for convenience)