Добрый день, хабраюзер.
Не так давно мы с другом начали делать небольшую текстовую игрушку в рамках фантастического проекта «Версум». В статье я хочу рассказать о тех проблемах, с которыми нам пришлось столкнутся, а так же о том, какие пути решения нами были выбраны.
Мы используем Python, в частности микрофреймворк Flask.
Устанавливаем Flask
Процесс достаточно простой
pip install flask pip install sqlalchemy pip install flask-sqlalchemy pip install alembic
В тех мануалах, которые попадались мне, для миграция используется sqlalchemy-migrate, но мне кажется он чуть более чем ужасен. У него зависимость от версии sqlalchemy, то есть для использования миграций надо специально подбирать версии друг к другу. К тому же на странице sqlalchemy-migrate так и написано:
Если вы хотите начать свой проект с участием SQLAlchemy и вам нужна миграция схем данных, то используйте Alembic
Грех не воспользоваться советом.
cd ~ mkdir flask cd flask alembic init alembic mkdir app_name
И переходим к следующему пункту.
Скелет приложения
Для написание простенького «Hello, World!» есть хороший мануал на официальном сайте. Но, наигравшись в песочнице, мы начали собирать скелет своего будущего приложения и получили первые проблемы, если можно так выразиться. Если Django навязывает нам свою структуру приложения, генерируя ее автоматически после startproject и startapp, то Flask дает нам полную свободу. Не знаю, стоит ли считать это «проблемой», но когда совершенно не знаешь куда копать становится грустно, и руки опускаются.
Однако, после длительной медитации над официальным учебником, после долгого разглядывания репозиториев на гитхабе (в частности поисковая выдача по запросу «flask skeleton»), после прочтения серии статей (автор Miguel Grinberg) — пришло некоторое прозрение и успокоение.
В конечном итоге скелет нашего приложения выглядит следующим образом:
~/flask |- /alembic |- /app_name | |- /static | | |- /css | | |- /js | | |- /img | |- /templates | | |- index.html | |- __init__.py | |- config.py | |- models.py | |- views.py |- alembic.ini |- README.md |- requirements.txt |- runserver.py
Пойдем по-порядку, flask — это корневая папка проекта, здесь инициализирован git, здесь создано виртуальное окружение, в общем лежит все, что относится к проекту, в том числе и файл запуска dev-сервера — runserver.py. Он достаточно прост, я пользуюсь им для запуска приложения на локальной машине:
#!/usr/bin/env python from app_name import app if __name__ == '__main__': if app.debug: app.run(debug=True) else: app.run(host='0.0.0.0')
Все самое необходимое, в том числе инициализация приложения и его модулей, происходит в __init__.py
import os FLASK_APP_DIR = os.path.dirname(os.path.abspath(__file__)) # Flask from flask import Flask app = Flask(__name__) # Config app.config.from_object('app_name.config.DevelopmentConfig') # ProductionConfig #app.config.from_object('app_name.config.ProductionConfig') # Connect to database with sqlalchemy. from flask.ext.sqlalchemy import SQLAlchemy db = SQLAlchemy(app) # Business Logic # http://flask.pocoo.org/docs/patterns/packages/ # http://flask.pocoo.org/docs/blueprints/ from app_name.views import frontend app.register_blueprint(frontend)
Сам же config.py выглядит следующим образом:
class Config(object): SECRET_KEY = 'some_secret' SITE_NAME = 'app_name.ru' SQLALCHEMY_DATABASE_URI = 'mysql://user:pass@localhost/tabe_name?charset=utf8' class ProductionConfig(Config): DEBUG = False TESTING = False class TestConfig(Config): DEBUG = False TESTING = True class DevelopmentConfig(Config): '''Use "if app.debug" anywhere in your code, that code will run in development code.''' DEBUG = True TESTING = True
Теперь чтобы достучатся до объекта app, который повсеместно используется в приложении (при условии, что в PYTHONPATH у вас добавлена папка flask):
from app_name import app
При этом подключается все необходимое для работы приложения.
При инициализации alembic в корне так же будет лежать alembic.ini, но нам его трогать надобности нет. Для интеграции с нашим приложением нужно будет залезть в файл env.py, который лежит внутри папки alembic.
В него после строчки # target_metadata = mymodel.Base.metadata надо дописать:
# target_metadata = mymodel.Base.metadata from app_name import db target_metadata = db.metadata
и переписать run_migrations_online:
def run_migrations_online(): """Run migrations in 'online' mode. In this scenario we need to create an Engine and associate a connection with the context. """ alembic_config = config.get_section(config.config_ini_section) from app_name import app alembic_config['sqlalchemy.url'] = app.config['SQLALCHEMY_DATABASE_URI'] engine = engine_from_config( alembic_config, prefix='sqlalchemy.', poolclass=pool.NullPool) connection = engine.connect() context.configure( connection=connection, target_metadata=target_metadata ) try: with context.begin_transaction(): context.run_migrations() finally: connection.close()
На этом интеграция alembic с нашим приложением завершена. Для автоматической миграции используем:
alembic revision --autogenerate -m 'some text'
При том создаются файлы миграций вида hashcode_some_text.py в папке versions. Желательно, а иногда даже необходимо, в них заглядывать. По словам самих же разработчиков, alembic не понимает переименования таблиц и полей, а так же плохо создает ключи.
Для применения миграции используем следующую команду:
alembic upgrade head
Последней строкой в файле config.py мы цепляем views.py, в котором хранится бизнес-логика. Минимальный набор для старта может быть таким:
from app_name import app, db from flask import Blueprint, request, render_template frontend = Blueprint('frontend', __name__) # 404 page not found "route" @app.errorhandler(404) def not_found(error): title = "404 Page not found" return render_template('404.html', title=title), 404 # 500 server error "route" @app.errorhandler(500) def server_error(error): title = "500 Server Error" db.session.rollback() return render_template('500.html', title=title), 500 # general routes @frontend.route('/') def index(): return render_template( 'index.html', title = u'Добро пожаловать', )
В самом начале добавлены хендлеры для ошибок, которые будут работать после отключения gebug. В общем, это все тот же «Hello, World!», но в расширенном варианте.
Файл models.py будет хранить наши модели, пока что он пуст. Со статикой и шаблонами, которые соответственно лежат в static и templates, вроде все понятно.
Запускаем на сервере
После запуска на сервере с nginx и uwsgi выяснилось, что при падении красивый деббагер не появляется. При старте сервера через runserver.py все хорошо, деббагер на месте.
Демон uwsgi пишет подробную информация об ошибках в свои логи, так что не все так плохо. Баг достаточно старый, по крайней мере нашелся годовалый вопрос на stackoverflow. Похоже, что это проблема самого uwsgi или их дружбы с nginx, но решить это недоразумение мы так и не смогли. Довольствуемся деббагером на локальной машине и сообщениями об ошибках на почту.
Надеюсь эта статья поможет сохранить немного времени тем, кто впервые будет писать свое приложение на Flask.
