Configure module installation path via Puppetfile

[fieg]

Puppet supports multiple module paths. It would be nice if you could instruct Librarian-puppet to install to a specific module directory. @rodjek opted against this in earlier issues (#9 and #120), but I would like the current maintainers to reconsider.

My use case would be:

Have librarian-puppet install to modules/vendor and have my own modules in modules/src. This allows you to have some custom modules without having to separating them in separate repositories and having them to pull in with librarian-puppet.

In case someone uses Vagrant, you can simply configure both module paths like this:

config.vm.provision :puppet do |puppet|
  puppet.module_path  = ["puppet/modules/vendor", "puppet/modules/src"]
  ...
end

[justenwalker]

Is there a reason why the --path argument to librarian-puppet does not support your use-case?

I tend to think of a Puppetfile like a Gemspec - its domain is to tell you what needs to be installed - but it doesn't know ultimately where they will go - that is the responsibility of the gem installer. Puppetfile is to Gemspec as Librarian Puppet is to Bundler.

If path information were added to Puppetfile, it would make it non-portable. In other words, I could not reasonably expect to take your Puppetfile and run it on my machine unmodified. you could have put path = /home/fieg/modules and I don't have that. This is probably why @rodjek decided against adding it in the issue you referenced.

[fieg]

Is there a reason why the --path argument to librarian-puppet does not support your use-case?

In that case I would have to instruct every co-worker about the extra flag they have to add when installing puppet modules. Of course I could write that down somewhere (and get lost, or forgotten), make something like a make script... OR have it stored as configuration in the Puppetfile inside the project. I would prefer the last.

I tend to think of a Puppetfile like a Gemspec ...

I not very familiar with ruby and related tools. But I tend to look at it similar to Composer (PHP package manager). They also store the path in the configuration file (vendor-dir). An other tool, Bower (Frontend package manager) allows you to store the path in a seperate file (bower.rc) inside the project.

If path information were added to Puppetfile, it would make it non-portable ...

Saving it as configuration inside the project makes is very portable the way I see it. Take my first argument against the --path parameter. My co-workers can check the project out and run librarian-puppet install and it works, just as I had it configured. Of course setting paths to outside the project root is something nobody should do.

[justenwalker]

I guess this is more of a philosophical point than a technical one: librarian-puppet as I understand it aims to be a close analogue to librarian-chef and the concept of install paths inside the manifest would mean deviating significantly from that.

Perhaps having the configuration option in .librarian/puppet/config is a more idiomatic alternative. Librarian will check this file and automatically add these options to the command-line so you won't need to remember to tell everyone.

# Saved in your project as .librarian/puppet/config
---
  LIBRARIAN_PUPPET_DESTRUCTIVE: "false"
  LIBRARIAN_PUPPET_PATH: "puppet/vendor/modules"
# Other config options follow the same pattern. LIBRARIAN_PUPPET_<NAME>=<VALUE>

As another alternative, are you familiar with r10k? It's another project which does something very similar to librarian-puppet. It uses an external file r10k.yaml to tell the program which paths to install modules. If the above work-around does not accommodate your use-case, maybe r10k will?

[fieg]

I didn't know about .librarian/puppet/config, but it sounds like a fine alternative.

[dgoodlad]

Just like .bundler/config, committing .librarian/puppet/config is generally considered A Bad Idea(tm).

The first time you run librarian-puppet it will write out that config file for you, based on whatever options you pass (like --path). So, if you have a setup script for your puppet repo, which runs for example bundle --local --binstubs bin && bin/librarian-puppet --path vendor/modules, the next time you manually run bin/librarian-puppet it will continue to install in vendor/modules.

[justenwalker]

@dgoodlad Good point. Isn't that exactly the behavior that @fieg wants though? I agree that it is a bad idea if the results it produces are unexpected. Is there another alternative I'm overlooking?