recent (2014-05-01) auto update breaks virtualenv compatibility again

[GoogleCodeExporter]

What steps will reproduce the problem?

fresh install of gcutils (download, unpack to separate directory, ./install.sh 
& default answers).

activate a virtualenv.

$ gcutil
Traceback (most recent call last):
  File "/zfs/shared/repos/google-cloud-sdk/platform/gcutil/gcutil", line 23, in <module>
    import platform
ImportError: No module named platform

What is the expected output? 

some help text, anything other than an import fail.

What do you see instead?

$ gcutil
Traceback (most recent call last):
  File "/zfs/shared/repos/google-cloud-sdk/platform/gcutil/gcutil", line 23, in <module>
    import platform
ImportError: No module named platform

What is the output of 'gcloud version'?

$ gcloud version
Google Cloud SDK 0.9.22

bq 2.0.18
bq-nix 2.0.18
core 2014.04.24
core-nix 2014.04.24
dns 2014.04.24
gcutil 1.15.0
gcutil-nix 1.15.0
gsutil 3.42
gsutil-nix 3.42
sql 2014.04.24

Please provide any additional information below.

OSX Mavericks, default python installed into virtualenv. 

Needing to deactivate a virtualenv *each* time I need to run a gcutil command 
is painful. Needing to keep a backup of google-cloud-sdk just in case the auto 
upgrade breaks is annoying.

Original issue reported on code.google.com by d...@jsonified.com on 1 May 2014 at 1:41

[GoogleCodeExporter]

via @skelterjohn in #gcloud irc,

export CLOUDSDK_PYTHON_SITEPACKAGES=1

works around this perfectly.

Original comment by d...@jsonified.com on 1 May 2014 at 9:47

[GoogleCodeExporter]

Original comment by jasm...@google.com on 16 May 2014 at 5:01

• Changed state: Accepted

[GoogleCodeExporter]

I'm wondering if CLOUDSDK_PYTHON_SITEPACKAGES=1 shouldn't be the default 
behavior, and something like CLOUDSDK_CUSTOM_SITEPACKAGES=1 should override?

Original comment by mbogos...@gmail.com on 17 May 2014 at 4:04