The sysutils/ansible port is broken.  This happened when the version was bumped to 2.4.0.0; a four year old regression was introduced that broke ansible for almost every remote system type.

The error is in the stanza of the Makefile:

post-patch:
        ${FIND} ${WRKSRC} -type f | ${XARGS} ${REINPLACE_CMD} \
                -e 's|/usr/bin/python|${PYTHON_CMD}|g' \
                -e 's|/etc/ansible|${ETCDIR}|g' \
                -e 's|/usr/share/ansible|${DATADIR}|g'


We must not replace the interpreter path '/usr/bin/python' in any of the modules (which run on the remote system).  This has the effect of hardwiring the BSD python in path into the modules and prevents the 'anisble_python_interpreter' variable from specifying the python path on the remote.  (The 'ansible_python_interpreter' mechanism searches for the unedited, default interpreter path.  If it is changed, ansible will fail unless /usr/local/bin/python2.7 is present on the remote system.  This prevents, for example, configuring linux systems with ansible running on FreeBSD.

As I mentioned, this problem has bitten the BSDs before.  See the thread:

https://groups.google.com/forum/#!topic/ansible-project/oM2FNuumWmw

The 2.3.x series ports did not have this problem, but they did not mess with the python path.

Here is an example of the bug in action.  I am using vagrant with the ansible provisioner to set up an Ubuntu 14.04.5 environment.  Here is the invocation of the playbook (output of ansible -vvvvv ....):

    sc2-container-host-raw: Running ansible-playbook...
PYTHONUNBUFFERED=1 ANSIBLE_NOCOLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit="sc2-container-host-raw" --inventory-file=/home/gitlab-runner/builds/e37c8767/0/spectrum-challenge/sc2-container-maker/.vagrant/provisioners/ansible/inventory -vvvv -e 'ansible_python_interpreter=/usr/bin/python' sc2-container-host.yml

The ansible_python_interpreter variable is set to /usr/bin/python (the path of python on the remote).  So modules should use that python as their interpreter on the remote.

However, the playbook fails the first time a python module tries to run on the remote because the BSD python path is hardwired:

fatal: [sc2-container-host-raw]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "module_stderr": "OpenSSH_7.2p2, OpenSSL 1.0.2k-freebsd  26 Jan 2017\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: auto-mux: Trying existing master\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 93068\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\ndebug3: mux_client_read_packet: read header failed: Broken pipe\r\ndebug2: Received exit status from master 0\r\nShared connection to 127.0.0.1 closed.\r\n", 
    "module_stdout": "/bin/sh: 1: /usr/local/bin/python2.7: not found\r\n", 
    "msg": "MODULE FAILURE", 
    "rc": 0
}

If we must, the scripts that run on the local host (e.g., ansible and ansible-playbook) could have their python paths edited to the port/pkg installed python.  However, the modules must remain untouched.

Best Regards,
Greg Wright