Спасибо за интерес к моей задаче)
Лучше объясни, что ты пытаешься сделать. Пока не поздно.
Хочу написать микрофреймворк на Flask. К серверу будут приходить запросы, на них нужно будет отвечать.
Идея была реализации через Class где будет один внешний метод для запуска Flask, а внутри во время разбора пришедшего запроса “дергаться” другие методы этого класса.
Видно, что ты плохо знаешь сам питон. Локальные импорты, например, не приняты, пишутся новичками, пока они не прочитали базовые вещи вроде PEP8.
Так как пишется готовый модуль. Модуль test.py планируется единственным. wsgi.py использует его методы.
Это вот пример, когда из-за цепочки ты не можешь понять, где именно произошла ошибка
Согласен. Эту цепочку вызовов будет сложно тестировать.
Я все же не пойму на чьей стороне ошибка. Это внутренние настройки gunicorn или особенность Heroku?
Думал, что все дело в модуле который gunicorn отслеживает для ответа на запрос. Но даже если принудительно передать __name__ из wsgi.py например так:
# file test.py
def servflask(nam):
from flask import Flask
app = Flask(nam)
@app.route("/")
def hello():
return "<h1 style='color:blue'>Hello There!</h1>"
return app
# file wsgi.py
from test import servflask
servflask(__name__).run()
То опять же, локально все работает. Но gunicorn начинает заваливать ошибками.
Exception in worker process
Хотя сервер запущен как и положено из основного модуля, явно указанного в app, о чем свидетельствует лог запуска:
Serving Flask app ‘wsgi’ (lazy loading)
Так как же запустить flask через функцию? Почему этого не удается сделать?