Use of memcache is a blocker to Python 3.7 migration

[rbubley]

main/cache.py uses memcache

This is not available in the Python 3.7 runtime.
Google suggests using Memorystore for redis, but this has no free tier, and gae-init is intended to work within the free tiers.

[rbubley]

I think re-coding to use Cloud Firestore for Datastore might be the way to go for a replacement.

[lipis]

It's happening.. I guess we could just drop it for now :)

These days I was thinking about the whole migration plan.. I guess we could do it in steps.. WDYT?

[rbubley]

Google suggest migrating service by service everything in the google.appengine namespace, then making the code py2/py3 compatible. Then the jump to py3 should be very easy.
I think the incremental approach should make migration easier — and this issue would then be the first of several: memcache, user, deferred, mail, ndb

[celiomarcos]

Hi!. Is there any evolution in the code to migrate to python3? you who are already aware of the needs, could you tell us at what points we can help in this migration? are any of the forks already advanced in this perhaps?

[rbubley]

@proudhon - I don't think there has been any evolution in the migration to python3. I'm sure any help would be welcome.

I think there are probably six issues that need to be dealt with, and they are mostly independent of each other, so you could dive into any of them that you were interested in. I think doing (1) first would make it slightly easier though. Consulting https://cloud.google.com/appengine/docs/standard/python3/python-differences will be useful.

1. Refactoring the requirements.txt / vendoring code -- under GAE Python 3, modules in requirements.txt are loaded automatically - some effort needs to be made to maintain the ability to develop and test locally (using a virtualenv) and for Travis to continue working.
2. Droppingmemcache
3. Dealing with use of user (not available in GAE Python 3) - will need to substitute.
4. Dealing with use of deferred - I think this could be done most simply with a POST to a special URL - if this can be done securely?
5. Dealing with use of mail - we already have an example of using mailgun -- maybe adding in an option to use one other, sendgrid? would suffice.
6. Dealing with use of ndb - will need to substitute - presumably with google-cloud-ndb.