[16.01] Fix virtual env handling broken with #1847.

[jmchilton]

Thanks for the bug report @natefoo.

[nsoranzo]

Should we add tests to Travis to check that these commands works, like we do for run.sh ?

[jmchilton]

I would say yes, but the existing travis check for run.sh is kind of noisy right? Does anyone know why it fails semi-frequently?

[dannon]

Kinda nitpicky, but now it prints twice:

[yoplait@anvil:~/galaxy] sh run_reports.sh                                                                                                                                                                                     29c78e9 ✭
Activating virtualenv at .venv
Activating virtualenv at .venv

[nsoranzo]

@jmchilton Is it? I haven't noticed many failures, but maybe somebody re-run the builds superfast.

[jmchilton]

I re-ran like 3 or 4 times - but admittedly it was all within a couple days about a week ago. Maybe it was some transient wheel or Travis problem that has been resolved.

[jmchilton]

@dannon good point, I've removed the print statements added with this PR.

[nsoranzo]

@dannon Actually also run.sh prints it twice, one for scripts/common_startup.sh and one for itself.

[natefoo]

It always printed it twice.

[dannon]

Sounds like we need to fix that in one more spot, then :)

Anyway, +1 for this change to 16.01.

[nsoranzo]

I think the double print is useful when debugging problems with virtual envs to check that scripts/common_startup.sh is sourcing the same env of run.sh . See also my next comment.

[nsoranzo]

This code must go AFTER ./scripts/common_startup.sh --skip-samples, which will create the .venv directory if it does not exist.

[jmchilton]

I've modified the order as requested by @nsoranzo.

[natefoo]

Merging this but we should probably switch to sourcing, further development in #1899