Repository navigation
protobuf issue when gcloud pip installed with -t flag #1624
Description
I am running into an issue that may be related to protocolbuffers/protobuf#1307. Freezing protobuf to 3.0.0b2 as recommended in that thread does not resolve the issue.
pip install gcloud works fine but pip install -t lib gcloud fails:
$ PYTHONPATH=lib/ python -c 'import gcloud.datastore'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/vmagent/app/lib/gcloud/datastore/__init__.py", line 53, in <module>
from gcloud.datastore.batch import Batch
File "/home/vmagent/app/lib/gcloud/datastore/batch.py", line 24, in <module>
from gcloud.datastore import helpers
File "/home/vmagent/app/lib/gcloud/datastore/helpers.py", line 22, in <module>
from google.protobuf.internal.type_checkers import Int64ValueChecker
ImportError: No module named google.protobuf.internal.type_checkers
This was tested on a clean GoogleCloudPlatform/python-docker image.
cffi==1.5.2
chardet==2.3.0
colorama==0.3.2
cryptography==1.2.3
enum34==1.1.2
gcloud==0.11.0
googleapis-common-protos==1.1.0
html5lib==0.999
httplib2==0.9.2
idna==2.0
ipaddress==1.0.16
mercurial==3.1.2
oauth2client==2.0.1
protobuf==3.0.0b2.post2
pyasn1==0.1.9
pyasn1-modules==0.0.8
pycparser==2.14
pyOpenSSL==0.15.1
requests==2.4.3
rsa==3.4
six==1.8.0
urllib3==1.9.1
virtualenv==13.1.2
This impacts the way that I was deploying gcloud to appengine (using the appengine vendor function). Any pointers on how to get gcloud up in appengine?
Thanks
Activity
theacodes commentedon Mar 17, 2016
Are you using the compat runtime or the new managed vms runtime?
natb1 commentedon Mar 17, 2016
I am using the compat runtime (though I realize the docker image I tested this with is intended for use with the MVM runtime)
theacodes commentedon Mar 17, 2016
This is a known (and very hairy) issue with the compat runtime. If you don't need any app engine APIs, I highly recommend you use the new MVMs runtime.
There are a few workarounds, so if you still want to use the compat runtime I have a few questions:
google.appengine.ext.vendorinappengine_config.py?natb1 commentedon Mar 17, 2016
My goal was to use
google.appengine.ext.vendorinappengine_config.py, but I think the test above isolates the issue from the vendor function. I have also tried using the vendor function and then importinggcloud.datastore(rather than just setting thePYTHONPATH) and I get the same result.theacodes commentedon Mar 17, 2016
I'm going to need a bit more detail here. Can you share your app.yaml, Dockerfile (if applicable), and
appengine_config.py? Can you tell me exactly what steps you're using to reproduce this?theacodes commentedon Mar 17, 2016
FYI, your test:
Is not valid. It's not enough to set
PYTHONPATH.libis actually a site-directory, andext.vendorexplicitly handles processing it as a site-directory. Namespace packages (such asgoogle) won't work at all unless processed in a site-directory.For completeness:
natb1 commentedon Mar 17, 2016
Ah, ic. That gets me somewhere. thanks. If I import the code that way it works and I can no longer reproduce using
google.appengine.ext.vendor. Sorry for the false alarm. Thanks very much for taking a look.theacodes commentedon Mar 17, 2016
Definitely not a false alarm and thank you for reporting this.
This only works for you because you're using vendoring (for really complicated reasons). If you decide to forego vendoring (FYI, the compat runtime will automatically read requirements.txt and install everything so you don't really have to vendor) let me know and I can see if our internal workaround will work for you.
docs: fix docstring with proto-plus dependency (#1624)
feat: adding domain-wide delegation flow in impersonated credential (#…
samples: add samples from pubsub/cloud-client (#134)
Updated google-cloud-pubsub to version 0.35 [(#1624)](GoogleCloudPlat…
chore: Add Sys test for move blob where name needs url encoding (#1624)
chore: update AI model in ai ops docs (#1624)