Just wondering about a couple module conventions that are developing
as I read and write modules.
1. Boolean params. This one I feel pretty strongly about. While I'm
glad that ansible is flexible about how modules are written, I think
an explicit policy for core modules would be best. Yes/No? True/False?
0/1? Case: lower, initial, insensitive?
2. 'debug' param. I'm not certain about this one, but given that
stderr is not the way to give debug info anymore, I think reserving a
boolean debug param meaning, "give me lots of information if something
goes wrong" would be helpful as people flesh out playbooks.
3. split("=",1). This is a subtle gotcha. Most core modules parse
params by shlex() then string.split("="). If a param contains a "=",
you'll crash your param parsing. Usually what's wanted is .split("=",
1)
FWIW,
--Brad
Just wondering about a couple module conventions that are developing
as I read and write modules.
1. Boolean params. This one I feel pretty strongly about. While I'm
glad that ansible is flexible about how modules are written, I think
an explicit policy for core modules would be best. Yes/No? True/False?
0/1? Case: lower, initial, insensitive?
We have already standardized on yes|no. Modules should lowercase
inputs but there should be no need to check for true, 't', 'y', 'yup',
'ok', 'reckon', etc
2. 'debug' param. I'm not certain about this one, but given that
stderr is not the way to give debug info anymore, I think reserving a
boolean debug param meaning, "give me lots of information if something
goes wrong" would be helpful as people flesh out playbooks.
Nope -- we should instead just use logging for what it changes here.
That's in plan for 0.5
3. split("=",1). This is a subtle gotcha. Most core modules parse
params by shlex() then string.split("="). If a param contains a "=",
you'll crash your param parsing. Usually what's wanted is .split("=",
1)
Yeah, though very few parameters need to take an = either.
We have already standardized on yes|no. Modules should lowercase
inputs but there should be no need to check for true, 't', 'y', 'yup',
'ok', 'reckon', etc
Great!
Nope -- we should instead just use logging for what it changes here.
That's in plan for 0.5
Also great!
> 3. split("=",1). This is a subtle gotcha. Most core modules parse
> params by shlex() then string.split("="). If a param contains a "=",
> you'll crash your param parsing. Usually what's wanted is .split("=",
> 1)
Yeah, though very few parameters need to take an = either.
Agreed, but it's nasty when it does.
Agreed, but it’s nasty when it does.
Yeah please patch any you find that work strangely.