This one was hard to catch, and probably the cause of many venv-related problems.

In essence, ./bin/cli.sh first makes sure that the cluster is up and running (docker compose up -d --no-recreate), and then execs into one of the CLI containers.

In a fresh environment, the call to docker compose up -d --no-recreate will start the containers and initialise the python virtual environment (i.e. will call ./bin/create_venv.sh). The latter takes a while to finish, and if we exec into the CLI before it finishes (which calls source ./bin/workon.sh), we break the installation.

This can be reproduced by (literally):

git clone https://github.com/faasm/faasm
cd faasm
git submodule update --init -f
./bin/refresh_local.sh
./bin/cli.sh faasm
bash: /usr/local/code/faasm/bin/../venv/bin/activate: No such file or directory
# inv -l does not work

The quick start tests circunvent this issue miraculously:

• When we run docker compose up, we do it on the nginx service (that does not start the cpp and python services).
• Then, when we start either the cpp or the python services, we docker compose run not docker compose exec (as the services had not been started before).
• This means that when we call ./bin/inv_wrapper.sh the ./venv directory is initialised from scratch correctly.

This issue was brought up thanks to #726.