Question

Contexte:J'écris une application Flask de taille moyenne (10 à 15 vues) et, ce faisant, j'espère organiser le code de manière à le rendre facilement maintenable et extensible (pas un fichier monolithique comme le sont la plupart des applications Flask).

La structure de l'application imite le Documentation comme suit:

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

Problème:Je ne parviens pas à faire travailler Foreman avec une application Flask qui ne s'appelle pas « app ».J'adorerais que run.py soit le point d'entrée de ma candidature.

J'utilise gunicorn + gevent et mon Procfile actuel contient :

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

j'ai utilisé run.py pour tester l'application :

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

J'ai donc supposé que je pouvais simplement remplacer run pour app dans le Procfile, mais lors de l'exécution foreman start , gunicorn échoue avec un verbiage dénué de sens sur les modules.

Était-ce utile?

La solution

J'ai trouvé la solution dans Documentation de Django.Le paramètre principal de gunicorn est le module :

gunicorn [OPTIONS] APP_MODULE

APP_MODULE est du modèle MODULE_NAME:VARIABLE_NAME

Bien qu'il semble logique que la syntaxe soit un argument de mot-clé app:someIdentifier, car tous les didacticiels utilisent un module nommé app, ce n'est en fait pas le cas.L'argument correct pour ma situation était run:app.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top