<p>gunicorn 20.0.0: --paste erkennt keine Argumente unter [server:main]</p>

Entschuldigen Sie. Der Changelog-Eintrag sagt nur „Simplify Paste Deployment Documentation“, und ich hätte helfen sollen, hier einen besseren News-Eintrag vorzubereiten.

Die PR dazu ist hier: https://github.com/benoitc/gunicorn/pull/1957

Zuvor hatten wir use = egg:gunicorn#main als veraltet markiert, aber das ist nicht mehr veraltet. Die Änderung soll die Rolle von Gunicorn in einer Paste Deploy-kompatiblen Umgebung verdeutlichen.

Es gibt zwei Möglichkeiten, Gunicorn mit dieser .ini -Datei zu verwenden.

Die erste Option ist die Verwendung der gunicorn CLI. Wenn Sie dies tun, müssen Sie Gunicorns eigene CLI-Flags oder Gunicorns eigenes Konfigurationsmodul (standardmäßig gunicorn.conf.py ) verwenden, um Serverargumente zu konfigurieren. Gunicorn bindet den Socket, verwaltet das Nachladen, schreibt PID-Dateien und so weiter. Gunicorn kann einen Abschnitt app in Ihrem .ini verwenden, um die aufrufbare Anwendung zu konfigurieren.

Die zweite Option ist die Verwendung eines Paste Script-Runners wie pserve . In diesem Fall verwaltet dieser Skript-Runner das Nachladen, schreibt PID-Dateien und so weiter. Die meisten anderen Optionen sollten weiterhin funktionieren, aber um den server -Block Ihrer .ini -Datei zu verwenden, müssen Sie einen Skript-Runner aufrufen, der mit Einfügen kompatibel ist. Gunicorn ist kein solcher Script Runner mehr.

Lassen Sie mich wissen, wenn ich mehr Klarheit hinzufügen kann.

In Ihrem Fall sollten Sie in der Lage sein, wie zuvor fortzufahren, aber verwenden Sie pserve anstelle von gunicorn , um Ihre Anwendung zu starten. Die gesamte Serverkonfiguration für Gunicorn kann sich dann in Ihrem server -Block befinden, wie Sie es anscheinend bereits getan haben.

Das vorherige Verhalten war möglicherweise verwirrend, da es die Angabe von Optionen in der Befehlszeile ermöglichte, die mit der Datei in Konflikt geraten würden. Wir hatten auch Anfragen zum Hinzufügen der Möglichkeit, Konfigurationsvariablen für die Interpolation in der .ini -Datei anzugeben und verschiedene server -Blöcke anzugeben (zusätzlich zu verschiedenen app -Blöcken). Infolgedessen wurde die Entscheidung getroffen, die Verwendung von Gunicorn als Paste _server_ Runner abzulehnen, anstatt zu versuchen, Unterstützung für all diese Funktionen hinzuzufügen. Die Gunicorn-CLI unterstützt jetzt das Lesen einer Paste Deploy .ini -Datei zum Erstellen einer Anwendung, aber die Verwendung server -Blöcken bleibt dedizierten Tools in diesem Ökosystem überlassen.

In Ihrem Fall sollten Sie in der Lage sein, wie zuvor fortzufahren, aber verwenden Sie pserve anstelle von gunicorn , um Ihre Anwendung zu starten.

Danke für die schnelle Antwort @tilgovi!

Nach deiner Empfehlung:

$ pserve development.ini
# ...
Starting server in PID 40148.
[2019-11-12 14:26:30 -0800] [40148] [INFO] Starting gunicorn 20.0.0
[2019-11-12 14:26:30 -0800] [40148] [INFO] Listening at: https://0.0.0.0:9090 (40148)
[2019-11-12 14:26:30 -0800] [40148] [INFO] Using worker: gevent
[2019-11-12 14:26:30 -0800] [40263] [INFO] Booting worker with pid: 40263

Was großartig ist, da ein Teil der internen PR, die ich eröffnet habe, darin bestand, den Befehl pserve in gunicorn zu ändern, was mir etwas misstrauisch war, da ich nicht der ursprüngliche Entwickler von unserem bin interner API-Server.

Das löst meine Probleme, Sie können dieses Problem gerne schließen =)

Danke,
Correy

Eine letzte Anmerkung, und ich glaube, ich habe alle Details hinzugefügt, an die ich mich erinnern kann. Es war möglicherweise verwirrend, dass der Aufruf gunicorn --paste production.ini Gunicorn als Server verwenden würde, _selbst wenn der Block server etwas anderes als egg:gunicorn#main _ spezifizierte!

Da Gunicorn in erster Linie ein Server- und Prozessmanager ist, macht es keinen Sinn, dass Gunicorn eine allgemeine CLI zum Aufrufen beliebiger Paste-kompatibler Server ist. Stattdessen ist Gunicorn ein Server, der Paste Deploy-Anwendungen unterstützt, und es ist ein mit Paste kompatibler Server. Es ist jedoch _kein_ ein Paste Script Runner CLI!

Ich habe dazu eine Ausgabe im Pyramid-Kochbuch eröffnet: https://github.com/Pylons/pyramid_cookbook/issues/222

Ich dachte, ich hätte dies gründlich in Gunicorn selbst dokumentiert, aber ich konnte die Referenz zunächst nicht finden. Es ist hier: http://docs.gunicorn.org/en/stable/run.html#paste -deployment

@tilgovi nur eine Vorwarnung, das war auch für mein Team eine bahnbrechende Veränderung. Vielleicht lohnt es sich, zum Breaking-Change-Teil des Changelogs zu wechseln?

Ich eröffne das Problem erneut und weise mich selbst zu. Ich werde es schließen, wenn ich das Änderungsprotokoll aktualisiere, damit es hier besser lesbar ist.

Nochmals, ich entschuldige mich dafür, dass ich es anfangs nicht deutlicher im Änderungsprotokoll genannt habe.

@tilgovi beule

Bitte teilen Sie mir mit, ob dies als separates Thema geöffnet werden soll.

Dies mag ein isoliertes Problem mit unserer Codebasis sein, aber nach ein wenig mehr Tests hat mein Team festgestellt, dass gunicorn 20.0.0 für unseren API-Server die Funktion pyramid_ldap3.get_ldap_connector .

gunicorn 20.0.0 :

Beim Start:

$ pip list | grep gunicorn
gunicorn             20.0.0
$ pserve bioapps/development.ini
[2019-11-20 15:55:30 -0800] [9902] [INFO] Starting gunicorn 20.0.0
[2019-11-20 15:55:30 -0800] [9902] [INFO] Listening at: https://0.0.0.0:10999 (9902)
[2019-11-20 15:55:30 -0800] [9902] [INFO] Using worker: gevent
[2019-11-20 15:55:30 -0800] [10034] [INFO] Booting worker with pid: 10034
/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

Nach dem Authentifizierungsversuch:

[2019-11-20 15:57:54,189] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 15:57:57,276] ERROR [exc_logger:114][DummyThread-1] 'https://bioappsdev02.bcgsc.ca:10999/session'
Traceback (most recent call last):
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/tweens.py", line 39, in excview_tween
    response = handler(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/router.py", line 156, in handle_request
    view_name
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/view.py", line 642, in _call_view
    response = view_callable(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/config/views.py", line 181, in __call__
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 390, in attr_view
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 368, in predicate_wrapper
    return view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 439, in rendered_view
    result = view(context, request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid/viewderivers.py", line 148, in _requestonly_view
    response = view(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/cornice/service.py", line 493, in wrapper
    response = view_(request)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 139, in session_post
    username, request.validated['password'], request,
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/bioapps/api/endpoints/session.py", line 27, in get_ldap_groups
    auth = connector.authenticate(username, password)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 208, in authenticate
    password=escape_for_search(password))
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 82, in execute
    with manager.connection() as conn:
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/pyramid_ldap3/__init__.py", line 165, in connection
    auto_bind=True, lazy=False, read_only=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 326, in __init__
    self.do_auto_bind()
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 343, in do_auto_bind
    self.bind(read_server_info=True)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/core/connection.py", line 585, in bind
    _, result = self.get_response(response)
  File "/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/ldap3/strategy/base.py", line 370, in get_response
    raise LDAPResponseTimeoutError('no response from server')
ldap3.core.exceptions.LDAPResponseTimeoutError: no response from server
[2019-11-20 15:57:57,298] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 500 206

gunicorn 19.9.0

Beim Start:

$ pip install gunicorn==19.9.0
Collecting gunicorn==19.9.0
  Using cached https://files.pythonhosted.org/packages/8c/da/b8dd8deb741bff556db53902d4706774c8e1e67265f69528c14c003644e6/gunicorn-19.9.0-py2.py3-none-any.whl
Installing collected packages: gunicorn
  Found existing installation: gunicorn 20.0.0
    Uninstalling gunicorn-20.0.0:
      Successfully uninstalled gunicorn-20.0.0
Successfully installed gunicorn-19.9.0
$ pip list | grep unicorn
gunicorn             19.9.0
$ gunicorn --paste bioapps/development.ini
[2019-11-20 16:03:45 -0800] [12015] [INFO] Starting gunicorn 19.9.0
[2019-11-20 16:03:45 -0800] [12015] [INFO] Listening at: https://0.0.0.0:10999 (12015)
[2019-11-20 16:03:45 -0800] [12015] [INFO] Using worker: gevent
[2019-11-20 16:03:45 -0800] [12018] [INFO] Booting worker with pid: 12018

Nach dem Authentifizierungsversuch:

[2019-11-20 16:04:39,292] INFO  [access:342][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:04:39,527] INFO  [access:362][DummyThread-1] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:10999/session HTTP/1.1" 200 639

Zwischen gunicorn 20.0.0 und gunicorn 19.9.0 wurden keine Änderungen an development.ini #$ vorgenommen.

Interessanterweise können wir den Fehler mit gunicorn 20.0.0 stoppen, wenn wir den Server mit folgendem Befehl starten:

$ pip list | grep unicorn
gunicorn             20.0.0
$ gunicorn --paste bioapps/development.ini -b 0.0.0.0:8999 --workers 1 --certfile /etc/ssl/certs/current/webserver.cer  --keyfile /etc/ssl/certs/current/private.key.u
[2019-11-20 16:14:27 -0800] [14783] [INFO] Starting gunicorn 20.0.0
[2019-11-20 16:14:27 -0800] [14783] [INFO] Listening at: https://0.0.0.0:8999 (14783)
[2019-11-20 16:14:27 -0800] [14783] [INFO] Using worker: sync
[2019-11-20 16:14:27 -0800] [14798] [INFO] Booting worker with pid: 14798

[2019-11-20 16:16:39,550] INFO  [access:342][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" {'username': 'colim', 'password': ''}
[2019-11-20 16:16:39,768] INFO  [access:362][MainThread] 10.9.202.54 - - "POST https://bioappsdev02.bcgsc.ca:8999/session HTTP/1.1" 200 639

Ich bin mir nicht sicher, ob es überhaupt einen Zusammenhang gibt, aber das Starten des Servers mit gunicorn 20.0.0 mit pserve ist das einzige Mal, dass wir diese Warnung sehen:

/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:53: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util.ssl_ (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/ssl_.py)', 'urllib3.util (/home/colim/Projects/bioapps/bioapps.api.ssl/centos7venv/lib/python3.6/site-packages/urllib3/util/__init__.py)'].
  monkey.patch_all()

@tilgovi was würdest du im changelog ändern?

@benoitc Ich möchte die Entfernung der Unterstützung für Paste Deploy-Serverdefinitionen in der Gunicorn-CLI hervorheben. Das kann ich heute.

Ist es in Ordnung, wenn ich das Änderungsprotokoll rückwirkend ändere, um es klarer zu machen (Abschnitt „Breaking Changes“ in Version 20.0 vornehmen)?

@CorreyL interessant! Sie können gunicorn definitiv mit den Optionen ausführen, die auf der Befehlszeile so angegeben sind. Ich denke, das ist die bevorzugte und sicherste Art, gunicorn auszuführen. Die Integration mit pserve ist praktisch, aber es ist schön zu wissen, dass sie hier Probleme verursacht. Ich hoffe, ich habe keinen Fehler gemacht, es abzulehnen.

Ist es in Ordnung, wenn ich das Änderungsprotokoll rückwirkend ändere, um es klarer zu machen (Abschnitt „Breaking Changes“ in Version 20.0 vornehmen)?

@tilgovi ja auf jeden Fall

@tilgovi kannst du diese Änderung heute hinzufügen? Wäre cool, es für 20.0.1 zu haben :)

Eine einzeilige Notiz zu c25563f hinzugefügt. Die Dokumentation wurde seit der Änderung bereits aktualisiert. Hoffentlich kann jeder, der diese Notiz sieht, die Dokumentation und diese Probleme finden. 😅

@tilgovi danke

Ich wollte nur eine weitere Bestätigung hinzufügen, dass ich davon überraschend betroffen bin. In meinem Fall war es nicht sehr bedeutsam, aber ich war verwirrt darüber, warum Gunicorn seit dem Upgrade das automatische Neuladen in der Entwicklung gestoppt hat, sowie einige andere geringfügige Verhaltensänderungen. Ich habe heute einige Zeit damit verbracht, es herauszufinden und festgestellt, dass die Einstellungen in meinen --paste INI-Dateien nicht mehr funktionieren, was mir geholfen hat, den Weg zu diesem Problem zu finden.

Ich habe keine Ahnung, ob dies machbar ist, aber wäre es möglich, Gunicorn eine Warnung ausgeben zu lassen, wenn es feststellt, dass Sie immer noch versuchen, Serverargumente über die Paster-Datei festzulegen?

Ich entschuldige mich für die Störung, @Deimos. Ich würde PRs überprüfen, aber ich habe keine konkreten Pläne, hier weitere hinzuzufügen.

Wie wäre es mit einem Fall, in dem Sie tatsächlich --paste zusammen mit --config verwenden möchten? Was in unserem Fall (RhodeCode) eine große Voraussetzung für die spezielle Logik der Speicherüberwachung ist, die wir in der Gunicorn-Konfiguration haben.

@marcinkuzminski das ist der ideale Anwendungsfall. Geben Sie einfach sowohl --paste als auch --config an. Gunicorn liest jedoch nicht den Abschnitt „Server“ der Paste-INI-Datei, da erwartet wird, dass Sie den Server in der Gunicorn-Konfigurationsdatei konfigurieren.

Das ist bedauerlich.

Wir liefern Gunicorn im Installationsprogramm an Kunden aus, und die gesamte Logik und Konfiguration wurde an die .ini-Dateien delegiert. So werden auch die meisten Beispiele über das Internet für Pyramid-Projekte angegeben.

Diese Änderung unterbricht das, und es ist wahrscheinlich einfacher für uns, gunicorn zu forken, um das zurückzubringen, und dann die Logik zu ändern und die Konfiguration in gunicorn_conf.py zu delegieren :(

Was wäre, wenn die --paste-Optionen mit einem speziellen Präfix gelesen würden. zB könnten Sie gunicorn mit --paste konfigurieren, aber es würde nur Konfigurationsoptionen lesen, denen gunicorn. vorangestellt wäre

z.B

gunicorn.arbeiter = 2
gunicor.XXX = YYY

Sie müssen nicht --config verwenden. Sie können die Einfüge-INI vollständig verwenden. Verwenden Sie dafür pserve statt gunicorn . Siehe die Dokumentation: https://docs.gunicorn.org/en/stable/run.html#paste -deployment

Die vorgenommene Änderung bestand lediglich darin, die Unterstützung für die Verwendung von Gunicorn als allgemeine Paste Deployment CLI zu entfernen, die Server ausführen kann. Gunicorn _ist immer noch selbst ein_ Paste-kompatibler Server.

Diese Änderung wurde vorgenommen, um potenzielle Verwirrung zu beseitigen, bei der eine .ini -Datei eine Kellnerin oder einen anderen Server in ihrem server -Block angeben würde, aber das Ausführen mit gunicorn --paste production.ini nicht wirklich verwenden würde Kellnerin überhaupt. Es wurde auch oft nach der Möglichkeit gefragt, einen anderen server -Block als server:main anzugeben. Die Aufrechterhaltung der Unterstützung für diese Funktionen, wenn vollkommen gute CLIs wie pserve dafür existieren, schien keinen Sinn zu machen.

Die gunicorn CLI kann eine Anwendungsdefinition aus einer INI-Datei lesen, verwendet jedoch ihre eigene Konfigurationsdatei zum Konfigurieren eines Servers. Verwenden Sie ein anderes Tool (wie pserve ) als Skript-/Prozess-Runner, wenn Sie die INI-Datei zum Konfigurieren eines Gunicorn-Servers verwenden möchten.

aber wir müssen --config zusammen mit --paste verwenden, wie in meinem 1. Kommentar.
In unserem Projekt wird alles von einer einzigen Konfigurationsdatei (.ini) verwaltet. Es gibt viel Upgrade-/Autoscale-Logik, die nur die .ini-Datei anpasst. Dann verwenden wir auch --config, um eine benutzerdefinierte Python-Konfiguration anzugeben, die festgelegt wird

• benutzerdefiniertes Logger-Format (dies ist technisch nicht möglich, mit der .ini-Datei angegeben zu werden)
• Arbeitsspeicherverwaltung (Python-Code)

Gunicorn ist Paste-kompatibel, aber die Funktionalität ist auf diese Weise eingeschränkt, und es hat ein Problem für uns geschaffen, von dem wir uns nicht erholen können, weil wir nicht 2 Konfigurationsdateien haben können, und auch das Verschieben zur Konfiguration in einer anderen Datei ist mehr Arbeit als das eigentliche Verzweigen Gunicorn und die Aufrechterhaltung dieser Gabel, nur um dieses Verhalten zurückzubringen.

Ich kenne die Gründe für dieses Ticket, aber wir haben Gunicorn und Kellnerin zusammen verwendet, und ich denke, Gunicorn-Binary auszuführen, ist eindeutig genug, IMHO. Außerdem denke ich, dass Sie sogar erkennen können, ob Benutzer ein anderes Ei verwenden, und es zu einem schweren Fehler machen.

Wir haben eine solche Verwendung nicht in Betracht gezogen, wenn ich mich erinnere. Wir können wahrscheinlich zurückbringen
die Unterstützung davon als Anwendungsfall klingt gut. Wäre es in Ordnung, eine zu haben
Log-Warnung dafür?

Am Freitag, den 16. Oktober 2020 um 08:28 Uhr Marcin Kuźmiński [email protected]
schrieb:

aber wir müssen --config zusammen mit --paste verwenden, wie in meiner 1
Kommentar.
In unserem Projekt wird alles von einer einzigen Konfigurationsdatei (.ini) verwaltet.
Es gibt eine Menge Upgrade-/Autoscale-Logik, die nur die .ini-Datei anpasst.
Dann verwenden wir auch --config, um eine benutzerdefinierte Python-Konfiguration anzugeben, die festgelegt wird

• benutzerdefiniertes Logger-Format (dies ist technisch nicht möglich
  angegeben mit .ini-Datei)
• Worker-Speicherverwaltung

Gunicorn ist pastenkompatibel, aber die Funktionalität ist auf diese Weise eingeschränkt,
und es hat ein Problem für uns geschaffen, von dem wir uns nicht erholen können.

Ich kenne die Begründung, aber wir haben Gunicorn und Kellnerin zusammen benutzt,
und ich denke, Gunicorn-Binary auszuführen, ist meiner Meinung nach eindeutig genug.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/benoitc/gunicorn/issues/2169#issuecomment-709838842 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAADRIQR2CLVUOYK6FDY2ZDSK7RZFANCNFSM4JMI65YA
.

>

Gesendet von meinem Handy

Ich dachte eigentlich an eine andere Lösung, wenn möglich. Bei der Verwendung von pserve mit Unicorn Egg wäre es auch schön, wenn die Konfigurationsdatei innerhalb der .ini-Datei gesetzt würde.

z.B

use = egg:gunicorn#main
workers = 2
config = /path/to/gunicorn_conf.py

Es würde also gunicorn_conf.py genau wie --config=/path/to/gunicorn_conf.py laden

Das obige würde also für uns funktionieren und es löst auch das Problem dieses Tickets. Ich bin mir nicht sicher, wie einfach und machbar das ist.

Andernfalls wäre es fantastisch, wenn Sie die Funktionalität zum Laden der Konfiguration aus der .ini-Datei beim Ausführen der Gunicorn-Binärdatei mitbringen könnten, das würde uns viel Ärger ersparen. Eine Warnung darüber ist kein Problem

Ich dachte eigentlich an eine andere Lösung, wenn möglich. Bei der Verwendung von pserve mit Unicorn Egg wäre es auch schön, wenn die Konfigurationsdatei innerhalb der .ini-Datei gesetzt würde.

Das sollte funktionieren und ist dokumentiert. Wenn dies nicht der Fall ist, melden Sie bitte einen Fehler!

Okay, wir prüfen das. Aber AFAIR gab es geringfügige Änderungen in der Funktionsweise der Gunicorn- und Pserve-Binärdateien. Soweit ich mich erinnere, hatte gunicorn --paste Zugriff auf den .ini-Dateipfad, während pserve mit gunicorn egg keinen Zugriff hatte. Wir werden dies prüfen und bei Bedarf ein entsprechendes Ticket eröffnen.