IssueTracker

It's already June, when will this bug be fixed?

I asked Gemini about it, but they didn't give me an answer. Haha

When gcloud sdk version 481 was released, I tried it, but dev_appserver still didn't work.

I wonder how long we'll have to continue using version 467.

It's disappointing that Google prioritizes fixing things that are cutting-edge and likely to attract public attention, while leaving a fatal bug like this one untouched.

Google has left this fatal bug in place for four months.

Google said.

"dev_appserver.py has moved to Python 3 and Python 2 is no longer supported. I don't know anymore issues."

But it still doesn't work with Python 3 yet. Why?

We pay a monthly fee which is not cheap. Get on with the job that needs to be done.

I'm getting the same "DatastoreGrpcStub requires a local gRPC" error described in #4 on a Debian Bookworm system with version 486.0.0 of the CLI. This seems like it's misleading, since this code in datastore_grpc_stub.py triggers the error for both grpc and grpc_service_pb2 import errors:

try:
  # ...
  import grpc
  from google.appengine.tools.devappserver2 import grpc_service_pb2
except ImportError:
  grpc = None
  grpc_service_pb2 = None

At least in my case, it's the grpc_service_pb2 import that's failing. When I comment out the try/except, I can see the actual error:

Traceback (most recent call last):
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/dev_appserver.py", line 103, in <module>
    _run_file(__file__, globals())
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/dev_appserver.py", line 99, in _run_file
    _execfile(_PATHS.script_file(script_name), globals_)
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/dev_appserver.py", line 81, in _execfile
    exec(open(fn).read(), scope)
  File "<string>", line 29, in <module>
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/api_server.py", line 44, in <module>
    exec(open(api_server_src).read())
  File "<string>", line 77, in <module>
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/datastore_converter.py", line 31, in <module>
    from google.appengine.tools.devappserver2 import datastore_grpc_stub
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/datastore_grpc_stub.py", line 38, in <module>
    from google.appengine.tools.devappserver2 import grpc_service_pb2
  File "/usr/lib/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/grpc_service_pb2.py", line 24, in <module>
    from google.net.proto2.python.public import descriptor as _descriptor
ModuleNotFoundError: No module named 'google.net'

I don't even have that google.net.proto2.python.public.descriptor file on my system, so it's unclear to me how this is supposed to work.

Happy New Year to you all!

It will soon be a year since I reported this bug.

When that happens, I will advertise that Google is a company that leaves bugs unfixed for a year.

Isn't it necessarily external?

For example, in the GoLang version of dev_appserver, the Datastore Emulator is not independent, but is started from within the same script.

Therefore, we programmers who use dev_appserver do not recognize the Datastore Emulator as an independent entity. (It can be treated as such, but other problems will arise.)

The problem this time is with the Datastore Emulator, which is started from within dev_appserver, and is an inseparable problem.

Even if we escalate, it will be Google's job, not ours. dev_appserver is not open source, after all.

As ludo@ mentions this is a duplicate of b/327666076 Also as ludo@ mentioned we have not prioritized this as the Cloud Datastore emulator is a beta product.

To be honest I do think fixing this would be an important benefit to our users but I never got too it... IIRC the root of the issue is an inconsistency between the internal grpc included with the dev appserver and the opensource version used by the datastore emulator (which i think is installed by the user maybe). I my guess is that it would be possible to fix this but based on https://yaqs.corp.google.com/eng/q/3586709184386695168 (mentioned in b/327666076) my approach is not currently supported (maybe it could be). Also it may be possible to post process the internal proto to make things work.

Another approach to solving the problem would be to move dev_appserver to an opensource build. That would be quite a big project and introduce questions of moss compliance.

Tested with gcloud 505.0.0. Still broken.　

I think it's a good idea to make the Datastore Emulator independent, but when I actually tried to access it from Java and GoLang's dev_server a while ago, it consumed too much memory and was unusable. (I haven't tried it recently.)

As the previous guy wrote, for us, the application programmers of appengine, the most important thing is that the dev_appserver runs stably.

It was Google that told us to move to Python3 and not to use Python2 anymore, right?

I'm not a Python programmer, and I don't agree with the tools being written in Python, but I hope that the dev_appserver will run stably on Python3.

I'm beginning to think that google is encouraging developers away from App Engine. Perhaps it's time to move on

That may be fine for new development, but it's not so easy for services that have already been developed and are in operation.

Once a service has been released and is up and running, it can't be stopped so easily. Google has a responsibility to maintain the AppEngine platform.

If they can't maintain it, they should present a proper migration roadmap.

Please maintain this platform. Don't leave the bugs in dev_appserver unfixed, fix them. AI is a low priority for us.

Regards. Thank you.