I run ansible from source, so my ANSIBLE_LIBRARY is set using hacking/env-setup.
However, I would like to be able to add additional libraries outside of ansible, without having a different env-setup (or not running it at all) or always passing the location on the command line.
I see two ways of doing this:
hacking/env-setup could read ANSIBLE_CONFIG and and add the contents of library to the ANSIBLE_LIBRARY path.
lib/ansible/constants.py could combine the config and ANSIBLE_LIBRARY values
There are probably other mechanisms (e.g. make the config file take precedence over the env variable, but that strikes me as worse)
Any thoughts as to better ways of doing this, or preferences over the two options (I think I like the second best, but open to other views).
One of the paths looked at is library/ in relation to the playbook you are executing. If you don't have a library/ there already, you could symlink that to the alternate path you wish to pull modules from when executing that particular playbook.
I would probably recommend just modifying the hacking/env-setup script to do what you want that is appropriate for your environment.
It’s basically there to enable development, not being a part of Ansible proper, so it doesn’t seem that core Ansible should change because of it, so much.
If an environment variable is set in Ansible, that overrides the file, and that’s pretty much standard across all the options.
A quick way around that would be to set PYTHONPATH and PATH, and then point ANSIBLE_CFG at a configuration file that did more of what you wanted.
But I’m trying to find a non-code solution, obviously. Since this really hasn’t come up before.
The “./library → symlink to /opt/mystuff/library” is a workaround, but I agree it’s non-intuitive.
Perhaps there’s an option with setting an additional environment variable that would be more agreeable?
What if hacking/env-setup set something called ANSIBLE_LIBRARY_PREFIX_PATH or something?
Yes, I’m sure I would have quite enjoyed discussion on this before creating the PR, but I didn’t have much response other than Jesse’s useful tip, which I did give due consideration, but in the end decided to come up with a code-based solution and discuss afterwards.
I would accept a custom env-setup, except that it’s not just me that uses Ansible here, but all of our configuration management machines too (and yes, we run from near-bleeding edge because the patches we need aren’t necessarily in devel yet, let alone in release). Obviously I could fork env-setup internally but my general principle is that nothing should go into internal versions that wouldn’t be accepted upstream (as really, I’d much rather run from release!)
Given it’s called hacking/env-setup, a much lower-tech solution might actually be to just add any library path from any configured config file into env-setup (I think there are a couple of ansible defaults and then ANSIBLE_CONFIG to check).
Are you suggesting setting ANSIBLE_LIBRARY_PREFIX_PATH in env-setup instead of ANSIBLE_LIBRARY? And then DEFAULT_MODULE_PATH becomes the combination of ANSIBLE_LIBRARY_PREFIX_PATH and whatever is contained in (1) ANSIBLE_LIBRARY or (2) config file library setting? That would probably be less gnarly than the combine_config_path (which as you say could be better documented)
“Given it’s called hacking/env-setup, a much lower-tech solution might actually be to just add any library path from any configured config file into env-setup”
Maybe we could do that programatically? Load constants.py with a stub python script after setting PYTHON_PATH and capture it in bash. (Basically make a quick hacking/get_library_path.py that env-setup could execute?)
