A few things:
- It is not just the 'python interpreter', modules can be written in
any language or even be binaries, modules that 'ship with Ansible' are
Powershell and Python, but that is not a limitation of the engine,
which makes it even harder to deal with.
- As much as 'per command granular
> > Also note that while run_command is used by some modules, the vast
> majority use APIs instead of running commands, so become is more
> geared to running the modules themselves
[...]
> what you ask for is not w/o reason, it is a niche use for a minority of
> modules and pushes
> against the de
I understand the request, but the push is to separate those concerns
as both from a security and simplicity perspective, action plugins
should not be able or care about 'become settings', much less take
part in manipulating module input.
Also note that while run_command is used by some modules, th
On Tue, Jul 12, 2022 at 10:30:58AM -0700, Brian Coca wrote:
> Actually I was already thinking of spliting _modify_module, for one, it
> should not need/handle/know about become_kwargs and we should eliminate the
> passing of these, which is kind of the opposite direction of your
> proposal.
I
Actually I was already thinking of spliting _modify_module, for one, it
should not need/handle/know about become_kwargs and we should eliminate the
passing of these, which is kind of the opposite direction of your
proposal.
As for action plugins, they already do too much and have too much
in
Since this didn't received replies yet and the above-mentioned PR was
closed with the following:
> However, we're absolutely always up for discussion.
> starting a discussion on the development list prior to implementing a
feature can make getting things included a little easier
... I'd like to
