Domanda

Contesto: Sto scrivendo un'applicazione di pallone di medie dimensioni (10-15 visualizzazioni), e nel processo, sperando di organizzare il codice in un modo che lo renderà facilmente mantenuta ed estensibile (non un file monolitico come la maggior parte delle applicazioni di pallone).

La struttura dell'applicazione imita il documentazione come segue:

/AwesomeHackings
    /ENV
    /AwesomeHackings
        /models
        /static
        /templates
        /__init__.py
        /awesome.py
        /awesome.cfg
    /Procfile
    /README.MD
    /requirements.txt
    /run.py
.

Problema: Non riesco a far funzionare il caposquadra con un'applicazione di pallone che non è nominata "app". Mi piacerebbe avere run.py essere il punto di ingresso alla mia applicazione.

Sto usando Gunicorn + Gevent, e il mio attuale procfile contiene:

web: gunicorn -w 2 -b 0.0.0.0:$PORT -k gevent app:run
.

Ho usato run.py per testare l'applicazione:

from AwesomeHackings import awesome
awesome.app.run(debug=True)
.

Così ho assunto di poter semplicemente sostituire run per app nel Procfile, ma quando si esegue foreman start, Gunicorn fallisce con verbosità senza senso sui moduli.

È stato utile?

Soluzione

Ho trovato la soluzione in Distanza di Django .Il parametro principale di Gunicorn è il modulo:

gunicorn [OPTIONS] APP_MODULE

Dove APP_MODULE è del modello MODULE_NAME:VARIABLE_NAME

Mentre sembrava logico per la sintassi di essere un'app di argomentazione della parola chiave: qualcuno elemosina, poiché tutti i tutorial utilizzano un modulo denominato app, in realtà non è il caso.L'argomento corretto per la mia situazione era run:app.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top