More robust use of our virtualenv

[jamezpolley]

Description

Prior to this change, the script tests if it's running inside a
virtualenv; and if it is, it assumes that it must be inside its own
virtualenv.

This change switches to testing for the activate binary in the
place we expect; and if it's found, using it directly. This avoids
false positives (running the script inside the wrong virtualenv) and
makes sure that we're running from inside the right
virtualenv.

Motivation and Context

I routinely run everything inside a virtualenv. This broke the script for me; it detected that it was inside a virtualenv and so it didn't attempt to activate its own virtualenv, so it couldn't find the ansible-playbook binary.

The existing docs at https://github.com/trailofbits/algo/blob/master/docs/troubleshooting.md#error-ansible-playbook-command-not-found boldly state that "You did not finish step 4 in the installation instructions". This is not correct: I did finish step 4; but the script did not use the virtualenv created in step 4.

How Has This Been Tested?

I ran it once on my machine and it worked for me.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
  I'm not sure if the doc section I mentioned should change. I think the docs are more correct after this change than they were before
• [] I have updated the documentation accordingly.
• [] I have added tests to cover my changes.
• [] All new and existing tests passed.

[CLAassistant]

All committers have signed the CLA.

[jamezpolley]

An alternative to ./env/bin/ansible-playbook would be to revert line 8 to sourcingenv/bin/activate and line 5 testing for the presence of that script - ie, just take away the misleading and irrelevant check to see if we're already in a virtualenv

[jackivanov]

@jamezpolley Could you accept the CLA and we will merge this?