Broken Python virtualenv = broken gcloud (gcloud should add -S more aggressively?)

[Evan Jones]

I think this is a bug in the gcloud wrapper script: If you have a broken Python configuration such that running "python" fails, you can't run gcloud. To fix it, the wrapper script could be more aggressive about passing "-S" to Python.

How to reproduce:

1. Create a new virtualenv: virtualenv bug

2. Create add a bad .pth file: echo "import broken" > bug/lib/python2.7/site-packages/broken.pth

3. Activate the virtualenv: source bug/bin/activate

4. Run gcloud: gcloud

Result:

An ImportError:

(bug) Chinook:~$ gcloud

Traceback (most recent call last):

  File ".../bug/lib/python2.7/site.py", line 703, in <module>

    main()

  File ".../bug/lib/python2.7/site.py", line 683, in main

    paths_in_sys = addsitepackages(paths_in_sys)

  File ".../bug/lib/python2.7/site.py", line 282, in addsitepackages

    addsitedir(sitedir, known_paths)

  File ".../bug/lib/python2.7/site.py", line 204, in addsitedir

    addpackage(sitedir, name, known_paths)

  File ".../bug/lib/python2.7/site.py", line 173, in addpackage

    exec(line)

  File "<string>", line 1, in <module>

ImportError: No module named broken

Expected result:

gcloud should continue to work; it should probably use the system Python configuration and avoid using the current virtualenv?

Details:

There seems to be code in the gcloud wrapper script that adds -S to python *unless* it is in a virtualenv. To me this logic seems backwards: shouldn't it add -S if it is *in* the virtualenv, to use the system packages instead?

At Bluecore we do a bunch of Python development. Every now and then someone does something to their virtualenv to kill it. They end up not being able to use gcloud until they figure out that virtualenv is the problem and fixing it. We have a script that attempts to set up our development environment that needs to actively detect virtualenv and avoid it, so that it can be sure that "gcloud" works, even when the user's Python configuration is screwed up.

Thanks!

Evan

[Zachary Newman]

Unfortunately, it's impossible to please everyone here. When we tried to ignore virtualenvs, people told us that they *wanted* to use the virtualenv Python, and they're more numerous (or at least louder) than the folks with your opinion.

If you keep encountering this, the best thing to do might be to set CLOUDSDK_PYTHON to point to a Python binary that works, and we'll ignore the virtualenv.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-dev/6e91a356-a065-49f9-92ee-bea3b55ea5e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evan Jones]

Ha! I guess I shouldn't be surprised by this answer. :) I guess I found it a bit surprising since I don't expect that the way gcloud runs should change when I switch into or out of a virtualenv, but I can see that people might want it the other way (particularly if your system Python is old or broken or something). Thanks for the rapid response and the workaround.

Evan

To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-d...@googlegroups.com.