Hi all,
We’re seeing some patterns where multiple modules might share very similar code (UserSearch is an example of a function which pretty much every module dealing with permissions needs). Currently these are implemented very similarly in each module.
I’d like to start discussing how we approach module which may require similar underlying functions such as UserSearch. As far as I can see, we have a couple of options:
Move them into powershell.ps1
Keep them separate from powershell.ps1, but refer to them in powershell.ps1. This would require us to do a run-time merge of powershell.ps1, “submodules”, variables and the module script itself
Keep them separate from powershell.ps1, but allow reference from each module by keywording #WANT_POWERSHELL_File_name.ps1 or similar. This would allow the module dev to choose which “common modules” to pull in. This would also (possibly) allow common shared modules to live outside of ansible core, so for instance if there’s 5 modules which does something using the same api there would be 5 module files + the common functions file for that module.
Combination of 2 and 3.
I just wanted to get the discussion started, any comments/opinions welcome!
Regarding 1, right now I don’t really want powershell.ps1 to get much bigger, but I might feel differently when put_file performance is increased (as per https://groups.google.com/forum/#!topic/ansible-devel/aAFdMPvYiFs)
2 feels like it could be painful to get working right.
So I think I favour 3. The trick is going to be getting the granularity right - too many different includes for little functions would be counter productive - too few would just make for bloated modules and/or module writers duplicating bits of functionality which we definitely want to avoid.
We have to agree on a tag which would work as the “trigger” for including, for example #INCLUDE: .ps1 or whatever. This is what module devs would use to reference functions
We need an understandeable search order for referencing function files. Something like:
Same dir as the module
Any module path
module_utils path (same path as powershell.ps1)
Again, not sure how this is solved on Python but it would definetely make sense to re-use any logic (at least as far as it makes sense given the language differences)
it will be hard to find the correct divide cause it requires us
divining what the future needs for common functions will for all the
unplanned modules.... http://dilbert.com/strip/1997-01-28
I think that adding to powershell.ps1 until there are enough functions
that can be grouped and split might be the 'least insane' way forward,
I don't know if we are there yet.
The module_utils is really a 'copy n paste' into the final script, so
there is a tradeoff with script size and code maintainability. I'm not
aiming for getting 'the right one'TM , just a big enough consensus by
the maintainers on where we should divide would suffice.
Functions for working with ansible (read/create parameters, creating the json response)
File-related functions (Get-FileChecksum)
User-related functions https://github.com/ansible/ansible/pull/12806/files
I think splitting stuff up into lots of different chunks could be counterproductive but I could live with 3 or 4 so something like
WANT_POWERSHELL_COMMON
WANT_POWERSHELL_FILETOOLS
WANT_POWERSHELL_USERTOOLS
… all of which just pull in .ps1 files from module_utils. Then there’s just one folder to look in for common code and the ‘api’ doesn’t start to get intimidatingly complex.
I’m not sure we need a way for modules to import their own copy-n-paste includes from anywhere else, at least at the moment, but maybe I could be persuaded otherwise if there are already some examples.
Maybe this is overkill and we can live with 400 lines of common powershell - basic.py is 1907 lines after all.
I concur- I don’t think we necessarily need to preemptively split into dozens of pieces, but an easily-extensible dynamic inclusion process is a Good Thing, especially for rarely-needed-but-should-be-shared-for-gods-sake stuff like the proposed “run as scheduled task” extensions.
On a related note: every customer I’ve done custom module work with has asked for a way to do this for their own code without hacking their Ansible installs (eg, allow module code-sharing from library/). I know similar things have been under discussion on the *nix side of the house for awhile, but last I checked, there’s been no consensus on how it should work- we’d face many of the same issues, I’m sure. I’d advocate for something relatively simple that follows the existing extensibility patterns (eg, a well-known directory name under the library path that we’d probe for X in the case of an unresolved #WANT_POWERSHELL_X). If we defined the resolution order clearly and added warnings for duplicate definitions of X, I think we could address much of the criticism of previous attempts at this sort of thing.
Its probably better to derive what needs to be common from things that we already have.