I appreciate you taking this step. Not going to argue about the paint.
Now that it’s too late, I’d like to beat this horse one last time. I realized a reason this may (or may not) matter: it prevents other languages from developing their own common modules.
Copying over a common module is not only less of a hack, but the same idea works in Ruby or Bash or what have you. Who will speak for the Bash programmers who want to use good software engineering? (I know, I know – both of them. The proposed system doesn’t let them.
Now, maybe you want to encourage people to write modules in Python (and I do), but I just want to make sure this is a conscious design decision, so when Ansible configures The World and the kids are writing modules in whizbang.js, they don’t curse our names for heedlessly forcing the same dirty hacks on them.
Now that it’s too late, I’d like to beat this horse one last time. I realized a reason this may (or may not) matter: it prevents other languages from developing their own common modules.
Definitely not so!
All that it would take is to have multiple inclusion symbols and to make those be provided by plugins, which could be entirely done server side by introspecting the shebang line, which the app already does for the ansible_python_interpreter magic.
Copying over a common module is not only less of a hack, but the same idea works in Ruby or Bash or what have you. Who will speak for the Bash programmers who want to use good software engineering? (I know, I know – both of them. The proposed system doesn’t let them.
We’ve had quite a lot of folks wanting less SSH hops and have taken steps to minimize them. This is my compromise to that, and the only way this would happen realistically while trying to maintain balance between people’s requests (yours, others). Ansible needs to transfer less individual things, not more. And this works in a very clean but elegant way. It’s performant and also fulfills the requirements.
Also in the vein of Ruby/whizbang/etc, the one thing I have been considering is whether it’s possible in an incompatible release (I’m talking about a 1.0, basically) to shift all modules to JSON input/output unless possibly bash was detected on their command line, and also getting them to read from standard input to avoid the file transfer of the arguments file altogether. This would make writing modules in more sophisticated languages a lot easier, and they really wouldn’t need much of a common module core at all. We originally made some compromises to support bash, and if we detect bash, we can still afford some sort of legacy mode for it, while moving the rest of things towards more simpler operation. Still theoretical, and nothing I’m trying to do immediately.
–Michael