I’ve been using Ansible lately and needed to be able to copy over Ansible modules that are compiled to executable binaries. While bash scripts, etc., work fine, it looks like Ansible runner’s _transfer_str() method that’s called on every module requires the module to be parseable UTF-8, which takes binaries out of the running.
At first glance, it looks like it should be easily solved with a few lines of code to allow a binary=True flag (or something) that the _copy_module() method could pass to _transfer_str(), but I was wondering: is this a problem that’s already been brought to light, with a workaround or a rationale as to why it shouldn’t be solved? If not, I could just patch this up, test it out, and send a pull request.
It’s been brought up a few times, I’d quite interested in patches that implemented this.
It probably seems that it could be dealt with my seeing if the file was binary (run ‘file’ or something better) and take care of business.
There’s definitely not a reason why this shouldn’t be solved, the 'old style" (non Python) module path will still pass in a “key=value” arguments line to the file passed to $ARGV[1] of the module, however. There’s a bit of a hack in there to tell if the module indicates it wants JSON data.
I suspect that if we detect the module is binary it should assume it wants JSON, since that’s going to be the better way to pass variables almost all of the time – what’s included there is for compatibility reasons and ease of use from bash more so than anything.
Does this make sense?
I’m definitely interested in patches for this, one or two people have been interested in modules written in Go, in particular.