Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Gevent compatability layer #647
This is a first (raw) draft implementing some of the ideas mentioned here: https://www.notion.so/Support-concurrency-backends-other-than-Eventlet-aefdf261f4344a05859321967dcdf42f
This code implements gevent (which is quite similar to eventlet but more widely used and better supported).
My thoughts are that it is a better starting point for discussing some Questions instead of on a completely white page.
A few Questions I had:
Holy cow @daviskirk! This is a huge step forwards
I think it should be possible to specify the concurrency backend with the configuration file. I had imagined that we'd have Nameko primitives in
In line with above, this is what I imagined
Good point. I don't particularly mind whether the Nameko concurrency primitives look more like eventlet, more like gevent, or forge their own path. The latter may be nicest. Ultimately I don't think Nameko has particularly complicated concurrency requirements, so simpler is probably better.
I think this is fine. I would be happy with websockets only being supported with the eventlet backend honestly.
Tangential point -- I would love to see extensions for an ASGI server like https://gitlab.com/pgjones/hypercorn available for Nameko. Hypercorn in particular is based on h11 and h2, which are sans-io libraries and therefore easy to use with any concurrency backend.
Ok, I think I'm ready for the next round. Thanks @mattbennett for your answers. Here a few comments:
Tests are now all passing for both gevent and eventlet
Did this, and seems to work well. However, the backend is still "set" once you import
This is true, I tried to just use the simplest api that seemed to fit for both. Nameko itself would probably be fine with a lot less primitives, most of the api compatibility layer is actually needed to run the tests in both environments.
I looked at this and think I get it, but this would probably be a separate pull right? I'm definitely not a pro in the ASGI space so I don't know how tricky it would be to actually build this.
Yes I think so. I would quite like everything in this package to go away eventually (it's only really used when starting and stopping extensions, which we already want to refactor with https://www.notion.so/namekopython/Refactor-sub-extension-management-380c0bfaea474e0f92b223cc7f33edae) but until then it makes sense to sit with the other concurrency primitives.
Moved it into the
mattbennett left a comment
I'm happy with these changes, and also have a project in mind to test a release candidate with.
I think we need to get v3 released (finally; @vlcinsky is pushing for this) and aim to have this out in 3.1. Rather than pushing a pre-release version to PyPI it might be more appropriate to install from this branch directly.