net: append -S to python invocation in the test server

net: append -S to python invocation in the test server

This will force using hermetic python libraries
instead of unpredictable system ones.

BUG=642190
Committed: https://crrev.com/6e48309c7f714cd8afb6ded20ef4adcc6b765624
Cr-Commit-Position: refs/heads/master@{#430895}

[Paweł Hajdan Jr., 2016-11-08 13:39:43]

The CQ bit was checked by phajdan.jr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-08 13:39:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-08 14:27:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-08 14:27:40]

Dry run: This issue passed the CQ dry run.

[Paweł Hajdan Jr., 2016-11-08 15:25:30]

phajdan.jr@chromium.org changed reviewers:
+ rch@chromium.org

[Paweł Hajdan Jr., 2016-11-08 15:25:30]

I'm not yet sure if it'll fix the bug, but it should make things more
predictable.

What do you think?

[Ryan Hamilton, 2016-11-08 22:11:18]

On 2016/11/08 15:25:30, Paweł Hajdan Jr. wrote:
> I'm not yet sure if it'll fix the bug, but it should make things more
> predictable.
> 
> What do you think?

Worth a shot, I think... lgtm

[Paweł Hajdan Jr., 2016-11-09 08:46:58]

The CQ bit was checked by phajdan.jr@chromium.org

[commit-bot: I haz the power, 2016-11-09 08:47:08]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-09 08:51:01]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-09 08:53:29]

Description was changed from

==========
net: append -S to python invocation in the test server

This will force using hermetic python libraries
instead of unpredictable system ones.

BUG=642190
==========

to

==========
net: append -S to python invocation in the test server

This will force using hermetic python libraries
instead of unpredictable system ones.

BUG=642190

Committed: https://crrev.com/6e48309c7f714cd8afb6ded20ef4adcc6b765624
Cr-Commit-Position: refs/heads/master@{#430895}
==========

[commit-bot: I haz the power, 2016-11-09 08:53:29]

Patchset 1 (id:??) landed as
https://crrev.com/6e48309c7f714cd8afb6ded20ef4adcc6b765624
Cr-Commit-Position: refs/heads/master@{#430895}

[mbjorge, 2016-11-22 18:57:37]

mbjorge@chromium.org changed reviewers:
+ mbjorge@chromium.org

[mbjorge, 2016-11-22 18:57:38]

This CL broke running net_unittests on the cast CQ internally. Our CQ runs with
a python virtualenv, and and running `python -S` inside the virtualenv results
in "ImportError: No module named base64"

It seems like another CL actually ended up fixing 642190. Could this CL possibly
get reverted? Alternatively, where do the "hermetic python libraries" come from,
and do those inlcude the standard libraries (like base64), perhaps I can find a
way to make our virtualenv pick those up?

[mbjorge, 2016-11-22 19:49:18]

Adding a -S has broken virtualenv's before. In another example, a check was done
where if we were in a virtualenv already, then the -S flag was not added
(https://codereview.chromium.org/2341173004/).

I'm not sure the best way to detect the presence of a virtualenv form C++ is
though. The preferred way in python, as done in the linked CL, is to check if
the sys module has a 'real_prefix' attribute. But if that's not feasible,
perhaps it would be easier to check for the presenence of the VIRTUAL_ENV
environment variable?