Gunicorn: ASGI-Unterstützung hinzufügen?

@arcivanov Ich werde mir dieses Protokoll genauer ansehen, um zu sehen, was dafür getan werden muss :)

Werde dieses Ticket so schnell wie möglich aktualisieren.

irgendwelche Updates?

@benoitc @berkerpeksag und ich haben per E-Mail darüber

Ich bin dabei, die ASGI-Spezifikation zu überarbeiten, damit sie für Server sowieso viel sinnvoller ist, also würde ich davor warnen, alles zu tun, bis das fertig ist (neue Spezifikation wird hier entworfen, ist aber noch nicht endgültig: http:/ /channels.readthedocs.io/en/2.0/asgi.html - es ist im Grunde viel mehr wie WSGI)

@andrewgodwin cool kann es kaum erwarten, Gunicorn mit Asgi auszuprobieren

@andrewgodwin wie ist der ASGI-Status?

Ich habe vor kurzem versucht, eine ASGI-App zu testen und Folgendes habe ich erhalten:

import json

def app(scope):
    async def channel(receive, send):
        message = await receive()

        if scope['method'] == 'POST':
            response = message
        else:
            response = scope

        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'Content-Type', b'application/json'],
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': json.dumps(response, default=bytes.decode).encode(),
        })
        await send({
            'type': 'http.disconnect',
        })
    return channel

> daphne app:app
2018-03-31 22:28:10,823 INFO     Starting server at tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,824 INFO     HTTP/2 support enabled
2018-03-31 22:28:10,824 INFO     Configuring endpoint tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,825 INFO     Listening on TCP address 127.0.0.1:8000
127.0.0.1:43436 - - [31/Mar/2018:22:28:17] "GET /" 200 347
127.0.0.1:43440 - - [31/Mar/2018:22:28:22] "POST /" 200 43
127.0.0.1:43446 - - [31/Mar/2018:22:28:42] "POST /" 200 54

> http -b get :8000/
{
    "type": "http"
    "http_version": "1.1",
    "method": "GET",
    "path": "/",
    "query_string": "",
    "root_path": "",
    "scheme": "http",
    "headers": [
        ["host", "localhost:8000"],
        ["user-agent", "HTTPie/0.9.9"],
        ["accept-encoding", "gzip, deflate"],
        ["accept", "*/*"],
        ["connection", "keep-alive"]
    ],
    "client": ["127.0.0.1", 43360],
    "server": ["127.0.0.1", 8000],
}

> http -b -f post :8000/ foo=bar
{
    "body": "foo=bar",
    "type": "http.request"
}

> http -b -j post :8000/ foo=bar
{
    "body": "{\"foo\": \"bar\"}",
    "type": "http.request"
}

https://github.com/django/asgiref/blob/master/specs/www.rst

@sirex ASGI ist jetzt stabil. Ich bin mir nicht sicher, ob Sie sagen, dass Daphne die Spezifikation einhält oder nicht?

Ist der Link auf Django der letzte über die ASGI-"Spezifikation", oder gibt es noch etwas, das den Ablauf beschreibt?

@andrewgodwin Ich habe versucht zu demonstrieren, dass, wenn Daphne ASGI unterstützt, ASGI bereit sein muss, damit andere Frameworks/Server übernommen werden können.

@benoitc gibt es zwei ASGI-Spezifikationsseiten:

https://github.com/django/asgiref/blob/master/specs/asgi.rst - allgemeine ASGI-Spezifikation.

https://github.com/django/asgiref/blob/master/specs/www.rst – Spezifikationen, die HTTP- und WebSockets-Protokolle und die Kompatibilität mit WSGI beschreiben.

@sirex danke. Obwohl diese Spezifikationen nicht sehr hilfreich sind, wenn es um die Implementierung geht.

Wie auch immer, ich habe https://channels.readthedocs.io/en/latest/ gefunden, was in Ordnung ist. Ich denke, ich würde einen Pep bevorzugen, aber wir können etwas vorschlagen, das Asgi unterstützt, sobald wir die Python-2-Unterstützung entfernt haben.

btw Letzten Kommentar gelöscht, da er nicht mit dieser Diskussion zusammenhängt.

Ich habe mich nicht dazu bewegt, ASGI zu einem PEP zu machen, da ich zuerst sicherstellen möchte, dass es genügend allgemeine Unterstützung hat (und dieser Prozess erfordert viel Zeit und Mühe), aber das ist die Absicht und sollte so geschrieben werden.

Wir können etwas vorschlagen, das Asgi unterstützt, sobald wir die Unterstützung für Python 2 entfernt haben.

Wenn Sie über die Implementierung nachdenken , lohnt es sich, mit

(Es könnte für uvicorn schön sein, dann einfach eine minimalere Option zu werden, ohne die Prozessüberwachung usw., die gunicorn bietet.)

Die ASGI-Spezifikationsdokumentation ist jetzt hier verfügbar: https://asgi.readthedocs.io/en/latest/.

Okay, habe das jetzt abgedeckt. (Als Drittanbieter-Workerklasse.)

Uvicorn 0.2 hängt nicht mehr von gunicorn ab, um es direkt auszuführen, sondern enthält zwei gunicorn-Worker-Klassen zum Ausführen von ASGI-Apps.

Für lokale Entwickler oder Fälle, in denen Sie sich nicht genug für die Prozessüberwachung interessieren, können Sie uvicorn einfach direkt ausführen. Für die Produktion dokumentieren wir die Verwendung einer Gunicorn-Klasse als bevorzugte Option.

http://www.uvicorn.org/#running -with-gunicorn

Führen Sie die ASGI-App von gunicorn aus mit uvloop und httptools aus:

gunicorn app:App -w 4 -k uvicorn.workers.UvicornWorker

Führen Sie die ASGI-App von gunicorn aus, mit asyncio und h11 (für Pypy-Kompatibilität):

gunicorn app:App -w 4 -k uvicorn.workers.UvicornH11Worker

Wenn der Wunsch besteht, eine der Protokollimplementierungen in das Kernpaket von gunicorn zu integrieren, dann bin ich sehr offen dafür, dies in Betracht zu ziehen.

Jetzt, da gunicorn python 2 nicht mehr unterstützt, ist es technisch machbar, ASGI Unterstützung hinzuzufügen

@tomchristie Mich interessiert, wie das aussehen würde. Als Alternative vielleicht die Protokolle als separates Paket oder separate Pakete extrahieren?

Mich interessiert, wie das aussehen würde. Als Alternative vielleicht die Protokolle als separates Paket oder separate Pakete extrahieren?

Ich vermute entweder eine Arbeiterklasse in gunicorn, die von uvicorn für die h11- und/oder httptools-Protokolle abhängig war. Oder duplizieren Sie die Implementierung hier.

Einen begrenzten Teil der Implementierung zu duplizieren, um Gunicorn integrierte ASGI-HTTP-Unterstützung mit einer h11 Abhängigkeit zu bieten, könnte eine gute Ausgangsbasis sein?

vielleicht die Protokolle als separates Paket oder Pakete extrahieren?

Es gibt nicht wirklich viel zu extrahieren aus uvicorn - Wenn wir click und nur argparse verwenden und unsere setup.py-Abhängigkeiten ein wenig optimieren, dann gibt es keine harten Abhängigkeiten mit verschiedenen Optionen für verschiedene HTTP-Implementierungen, WS-Implementierungen, Event-Schleifen.

Ich hätte gerne eine erstklassige ASGI-Unterstützung, sei es, um zusätzliche Abhängigkeiten in Gunicorn hinzuzufügen, einen Stub-Worker, der Ihnen sagt, was Sie installieren müssen, Dokumentation oder etwas anderes.

ja bitte. bin dabei, von gunicorn auf daphne umzusteigen .. wenn gunicorn nur asgi . unterstützen könnte
das würde mir so viel zeit sparen.

@japrogrammer http://www.uvicorn.org/#running -with-gunicorn

Django 3.0 (wird im Dezember 2019 veröffentlicht) wird ASGI-Unterstützung standardmäßig haben , also ist dies ein weiterer gunicorn , es direkt zu unterstützen. Nach der Veröffentlichung werden wir wahrscheinlich einen großen Anstieg des Benutzerinteresses feststellen.

@Johnthagen das ist auf der Pfeife. Allerdings müssen wir die Tickets noch ein wenig aufklären und diesen Monat vor dem Start eine Freigabe machen.