Мега-Учебник Flask Глава 1: Привет, мир! ( издание 2018 )

blog.miguelgrinberg.com


Miguel Grinberg




>>> следующая глава >>>


Эта статья является переводом нового издания учебника Мигеля Гринберга. Прежний перевод давно утратил свою актуальность.


Автор планирует завершить его выпуск в мае 2018. Я, со своей стороны, постараюсь не отставать с переводом.


Для справки ниже приведен список статей этой серии.



Новый учебник написан в 2017 году, и, наконец, он выглядит так, как если бы он был настроен на версию Python 3. Решены проблемы с совместимостью, изменен фокус в сторону Python 3, а не Python 2 как было в 2012 году в прежней версии учебника.


К сожалению, Python 2 или 3 — это не единственное, что изменилось. Есть также несколько технологий, которые имели смысл в 2012 году, но теперь устарели. К ним относятся:


  • Механизм аутентификации OpenID, который больше не поддерживается многими провайдерами.
  • Пакет sqlalchemy-migrate для миграции баз данных, который, похоже, так же потерял поддержку сообщества. В эти дни Alembic — намного более лучший выбор для миграции чем SQLAlchemy.
  • Интерфейс командной строки Flask (Flask Shell), который в то время не существовал, а теперь является незаменимым инструментом разработчика.
  • В то время, когда Мигель начал работать над учебником, Flask blueprints были слишком новыми, поэтому он решил не использовать эту функцию. В 2017 году blueprints являются обязательными для применения в Flask.
  • Bootstrap 2 для стилизации и форматирования веб-страниц, теперь имеет две основные версии. Новые версии Bootstrap не имеют обратной совместимости с версией 2.
  • Изменения в сервисе Heroku, инструкции по развертыванию которые представлены учебнике устарели.

Многие вещи, которые изменились за эти пять лет, в основном означают, что нужно пересмотреть все главы, причем большинство из них претерпели довольно важные изменения.


Сам Мигель считает, что вырос профессионально за эти пять лет, и думает, что сможет принести гораздо большую ценность этому учебнику с этим новым опытом. После выхода первого учебника он провел более дюжины конференций и выпустил кучу учебных пособий, написал очень успешную книгу разработки Flask для крупного издательства, создал несколько популярных проектов с открытым исходным кодом .


Кроме того, у Мигеля есть еще пять лет опыта работы в качестве технического блоггера, так как продолжал создавать контент для своего блога на протяжении всех этих лет. Весь этот опыт будет отражен в обновлениях, которые он приводит в учебнике.


Более подробно читайте в блоге Мигеля


VIDEO


Добро пожаловать!


Вы собираетесь отправиться в путешествие, чтобы узнать, как создавать веб-приложения с помощью Python и микрофреймворка Flask. Видео выше даст вам обзор содержимого этого руководства. В этой первой главе вы узнаете, как настроить проект Flask. В конце этой главы у вас будет простое веб-приложение Flask, работающее на вашем компьютере!


Примечание 1: Если вы ищете старые версии данного курса, это здесь.


Примечание 2: Если вдруг Вы хотели бы выступить в поддержку моей(Мигеля) работы в этом блоге, или просто не имеете терпения дожидаться неделю статьи, я (Мигель Гринберг)предлагаю полную версию данного руководства упакованную электронную книгу или видео. Для получения более подробной информации посетите learn.miguelgrinberg.com.


Все примеры кода представленные в этом учебном курсе, размещенный на GitHub. Загрузка кода из GitHub поможет вам сэкономить время, но я настоятельно рекомендуем введите код самостоятельно, по крайней мере, первые несколько глав. После того, как вы станете больше знакомы с Flask можно получить доступ к коду прямо из GitHub, в том случае, если ввод становится слишком утомительным.


В начале каждой главы, Я дам вам три GitHub ссылки, которые могут быть полезны при изучении главы. Browse откроет GitHub репозиторий для микроблога в том месте, где собраны изменения к главе, которую Вы читаете, за исключением любых изменений, внесенных в будущих главах. Zip — это ссылка для загрузки zip-архива, в том числе приложения и изменений в главе. Diff — откроет графическое представление всех изменений, внесенных в главу, которую Вы собираетесь читать.


На GitHub ссылки в этой главе: Browse, Zip, Diff.


Установка Python


Если на вашем компьютере не установлен Python, установите его. Если ваша операционная система не имеет предустановленный пакет Python, вы можете скачать программу установки с официального сайта Python. Если вы используете Microsoft Windows вместе с WSL или Cygwin, обратите внимание, что вы не будете использовать родную версию Python для Windows, а версию, совместимую с Unix, которую вам нужно получить от Ubuntu (если вы используете WSL) или от Cygwin.


Чтобы убедиться, что ваша установка Python является функциональной, вы можете открыть окно терминала и ввести python3, или если это не работает, просто python. Вот что вам следует ожидать:


$ python3
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> _

или так в cmd (окно командной строки Microsoft Windows) :


c:\cp>c:\python33\python
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:37:12) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

Интерпретатор Python теперь находится в ожидании пользовательского ввода. В будущих главах вы узнаете, для чего это интерактивное приглашение полезно. Но пока Вы подтвердили, что Python установлен в вашей системе. Чтобы выйти из интерактивного приглашения, вы можете ввести exit() и нажать Enter.


В версиях Python для Linux и Mac OS X вы также можете выйти из интерпретатора, нажав Ctrl-D.


В Windows, ярлык выхода — Ctrl-Z, затем Enter.


Установка Flask


Следующий шаг — установить Flask, но прежде чем я расскажу об этом, я хочу рассказать вам о лучших методах, связанных с установкой пакетов Python.


В Python пакеты, такие как Flask, доступны в общем репозитории, откуда их можно загрузить и установить. Официальный репозиторий пакетов Python называется PyPI, что означает Python Package Index (также известный, как «cheese shop»). Установка пакета из PyPI очень проста, потому что у Python есть инструмент под названием pip, который выполняет эту работу (в Python 2.7 pip не входит в комплект с Python и его нужно устанавливать отдельно).


Чтобы установить пакет на свой компьютер, вы используете pip следующим образом:


$ pip install <package-name>

Интересно, что этот метод установки пакетов не будет работать в большинстве случаев. Если ваш интерпретатор Python был установлен глобально для всех пользователей вашего компьютера, велика вероятность того, что ваша обычная учетная запись пользователя не получит разрешения на внесение в нее изменений, поэтому единственный способ выполнить вышеприведенную команду — запустить ее от имени администратора. Но даже без этого осложнения поймите, что происходит, когда вы устанавливаете пакет, как указанным выше способом. Инструмент pip загрузит пакет из PyPI, а затем добавит его в вашу папку Python. С этого момента каждый скрипт Python, который у вас есть в вашей системе, будет иметь доступ к этому пакету. Представьте ситуацию, когда вы закончили веб-приложение с использованием версии 0.11 Flask, которая была самой последней версией Flask при запуске, но теперь она была заменена версией 0.12. Теперь вы хотите запустить второе приложение, для которого вы хотели бы использовать версию 0.12, но если вы замените установленную версию 0.11, вы рискуете сломать свое старое приложение. Вы видите проблему? Было бы идеально, если бы можно было установить Flask 0.11, который будет использоваться вашим старым приложением, а также установить Flask 0.12 для Вашего нового.


Чтобы решить проблему поддержки различных версий пакетов для разных приложений, Python использует концепцию виртуальных сред. Виртуальная среда — это полная копия интерпретатора Python. Когда вы устанавливаете пакеты в виртуальной среде, общесистемный интерпретатор Python не затрагивается, только копия. Таким образом, решение иметь полную свободу для установки любых версий ваших пакетов для каждого приложения — использовать другую виртуальную среду для каждого приложения. Виртуальные среды имеют дополнительное преимущество, они принадлежат пользователю, который их создает, поэтому им не требуется учетная запись администратора.


Начнем с создания каталога, в котором будет жить проект. Я собираюсь назвать этот каталог microblog, так как это имя приложения:


$ mkdir microblog
$ cd microblog

Если вы используете версию Python 3, в нее включена поддержка виртуальной среды, поэтому все, что вам нужно сделать для ее создания, это:


$ python3 -m venv venv

С помощью этой команды Python запустит пакет venv, который создает виртуальную среду с именем venv. Первым venv в команде является имя пакета виртуальной среды Python, а второе — имя виртуальной среды, которое я буду использовать для этой конкретной среды. Если вы считаете, что это сбивает с толку, вы можете заменить второй venv другим именем, которое вы хотите назначить своей виртуальной среде. В общем, я создаю свои виртуальные среды с именем venv в каталоге проекта, поэтому всякий раз, когда я подключаюсь к проекту, я нахожу его соответствующую виртуальную среду.


Обратите внимание, что в некоторых операционных системах вам может понадобиться использовать python вместо python3 в приведенной выше команде. Некоторые установки используют python для релизов Python 2.x и python3 для релизов 3.x, в то время как другие отображают python в выпусках 3.x.


По завершении команды вы будете иметь каталог с именем venv, где хранятся файлы виртуальной среды.


Если вы используете любую версию Python старше 3.4 (включая выпуск 2.7), виртуальные среды не поддерживаются изначально. Для этих версий Python вам необходимо загрузить и установить сторонний инструмент virtualenv, прежде чем создавать виртуальные среды. После того, как virtualenv установлен, вы можете создать виртуальную среду со следующей командой:


$ virtualenv venv

или так


$ python virtualenv.py venv

Прим.переводчика: У меня установлено несколько версий Python. Я использую Python3.3. В моем случае пришлось вводить строку так:


C:\microblog>c:\Python33\python.exe c:\Python33\Lib\site-packages\virtualenv.py venv

В полученном сообщении видно, что установлен pip и ряд пакетов:


Using base prefix 'c:\\Python33'
New python executable in C:\microblog\venv\Scripts\python.exe
Installing setuptools, pip, wheel...done.

Независимо от метода, который вы использовали для его создания, вы создали свою виртуальную среду. Теперь вам нужно сообщить системе, что вы хотите ее использовать, активируя ее. Чтобы активировать новую виртуальную среду, используете следующую команду:


$ source venv/bin/activate
(venv) $ _

Если вы используете cmd (окно командной строки Microsoft Windows), команда активации немного отличается:


$ venv\Scripts\activate
(venv) $ _

Когда вы активируете виртуальную среду, конфигурация сеанса терминала изменяется так, что интерпретатор Python, хранящийся внутри нее, станет тем, который вызывается при вводе python. Кроме того, в запросе терминала включено имя активированной виртуальной среды. Изменения, внесенные в сеанс терминала, являются временными и частными для этого сеанса, поэтому они не будут сохраняться при закрытии окна терминала. Если вы одновременно работаете с несколькими терминальными окнами, отлично видно, чтобы на каждом из них были задействованы разные виртуальные среды.


Теперь, когда вы создали и активировали виртуальную среду, вы можете, наконец, установить в нее Flask:


(venv) C:\microblog>pip install flask
Collecting flask
  Using cached Flask-0.12.2-py2.py3-none-any.whl
Requirement already satisfied: click>=2.0 in c:\python33\lib\site-packages (from flask)
Requirement already satisfied: Werkzeug>=0.7 in c:\python33\lib\site-packages (from flask)
Requirement already satisfied: Jinja2>=2.4 in c:\python33\lib\site-packages (from flask)
Requirement already satisfied: itsdangerous>=0.21 in c:\python33\lib\site-packages (from flask)
Requirement already satisfied: markupsafe in c:\python33\lib\site-packages (from Jinja2>=2.4->flask)
Installing collected packages: flask
Successfully installed flask-0.12.2

(venv) C:\microblog>

Если вы хотите проверить, что в вашей виртуальной среде установлен Flask, вы можете запустить интерпретатор Python и импортировать Flask в него:


(venv) C:\microblog>python
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:37:12) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import flask
>>>

Если этот импорт не дает вам никаких ошибок, вы можете поздравить себя, так как Flask установлен и готов к использованию.


Flask приложение «Привет, мир»


Если вы зайдете на сайт Flask, вас приветствует очень простое примерное приложение с пятью строками кода. Вместо того, чтобы повторять этот тривиальный пример, я покажу вам немного более сложный, который даст вам хорошую базовую структуру для написания больших приложений.


Приложение будет существовать в виде пакета.


Прим.переводчика: Пакет — это коллекция модулей.


В Python подкаталог, содержащий файл __init__.py, считается пакетом и может быть импортирован. Когда вы импортируете пакет, __init__.py выполняет и определяет, какие символы предоставляют пакет для внешнего мира.


Давайте создадим пакет под названием app, в котором будет размещено приложение. Убедитесь, что вы находитесь в каталоге microblog, а затем выполните следующую команду:


(venv) $ mkdir app

__init__.py для пакета приложения будет содержать следующий код:


from flask import Flask

app = Flask(__name__)

from app import routes

Сценарий выше просто создает объект приложения как экземпляр класса Flask, импортированного из пакета flask. Переменная __name__, переданная в класс Flask, является предопределенной переменной Python, которая задается именем модуля, в котором она используется. Flask использует расположение модуля, переданного здесь как отправную точку, когда ему необходимо загрузить связанные ресурсы, такие как файлы шаблонов, которые я расскажу в главе 2. Для всех практических целей передача __name__ почти всегда будет настраивать flask в правильном направлении. Затем приложение импортирует модуль routes, который еще не существует.


Один из аспектов, который может показаться запутанным вначале, состоит в том, что существуют два объекта с именем app. Пакет приложения определяется каталогом приложения и сценарием __init__.py и указан в инструкции routes импорта приложения. Переменная app определяется как экземпляр класса Flask в сценарии __init__.py, что делает его частью пакета приложения.


Другая особенность заключается в том, что модуль routes импортируется внизу, а не наверху скрипта, как это всегда делается. Нижний импорт является обходным путем для циклического импорта, что является общей проблемой при использовании приложений Flask. Вы увидите, что модуль routes должен импортировать переменную приложения, определенную в этом скрипте, поэтому, поместив один из взаимных импортов внизу, вы избежите ошибки, которая возникает из взаимных ссылок между этими двумя файлами.


Так что же входит в модуль routes? routes — это разные URL-адреса, которые приложение реализует. В Flask обработчики маршрутов приложений записываются как функции Python, называемые функциями просмотра. Функции просмотра сопоставляются с одним или несколькими URL-адресами маршрутов, поэтому Flask знает, какую логику следует выполнять, когда клиент запрашивает данный URL-адрес.


Вот ваша первая функция просмотра, которую вам нужно написать в новом модуле с именем app/routes.py:


from app import app

@app.route('/')
@app.route('/index')
def index():
    return "Hello, World!"

Эта функция просмотра на самом деле довольно проста, она просто возвращает приветствие в виде строки. Две странные строки @app.route над функцией — декораторы, уникальная особенность языка Python. Декоратор изменяет функцию, которая следует за ней. Общий шаблон с декораторами — использовать их для регистрации функций как обратных вызовов для определенных событий. В этом случае декоратор @app.route создает связь между URL-адресом, заданным как аргумент, и функцией. В этом примере есть два декоратора, которые связывают URL-адреса / и /index с этой функцией. Это означает, что когда веб-браузер запрашивает один из этих двух URL-адресов, Flask будет вызывать эту функцию и передать возвращаемое значение обратно в браузер в качестве ответа. Если вам кажется, что это еще не имеет смысла, это будет недолго, пока вы запустите это приложение.


Чтобы завершить приложение, вам нужно создать сценарий Python на верхнем уровне, определяющий экземпляр приложения Flask. Давайте назовем этот скрипт microblog.py и определим его как одну строку, которая импортирует экземпляр приложения:


from app import app

Помните два объекта app? Здесь вы можете видеть оба вместе в одном предложении. Экземпляр приложения Flask называется app и входит в пакет app. from app import app импортирует переменную app, входящую в пакет app. Если вы считаете это запутанным, вы можете переименовать либо пакет, либо переменную во что то другое.


Чтобы убедиться, что вы все делаете правильно, ниже приведена диаграмма структуры проекта:


microblog/
  venv/
  app/
    __init__.py
    routes.py
  microblog.py

Верьте или нет, но первая версия приложения завершена! Прежде чем запускать его, Flask нужно сообщить, как его импортировать, установив переменную среды FLASK_APP:


(venv) $ export FLASK_APP=microblog.py

Если вы используете Microsoft Windows, используйте команду 'set' вместо 'export' в команде выше.


Готовы ли вы быть потрясены? Вы можете запустить свое первое веб-приложение со следующей командой:


(venv) $ flask run
 * Serving Flask app "microblog"
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

Прим.переводчика: Я был потрясен поскольку получил ошибку кодировки. Если у вас версия Python старше 3.6 вас скорее всего ждет сюрприз. Типа:


Syntax Error: (unicode error) 'utf-8' codec can't decode byte 0xcf in position 0: invalid continuation byte:

В моем случае виноваты кириллические символы ПК в имени компьютера. Заменил на PK и все заработало. Виноват модуль socket


(venv) C:\microblog>python
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:37:12) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from socket import gethostbyaddr
>>> gethostbyaddr('127.0.0.1')
('Acer-PK', [], ['127.0.0.1'])
>>>

Действительно все заработало:


(venv) C:\microblog>set FLASK_APP=microblog.py

(venv) C:\microblog>flask run
 * Serving Flask app "microblog"
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)


Что бы написать по русски "Привет, Мир!" потребуется скорректировать
модуль routes.py


Добавить строку # -*- coding: utf-8 -*-


# -*- coding: utf-8 -*-
from app import app

@app.route('/')
@app.route('/index')
def index():
    return "Привет, Мир!"


Когда вы закончите играть с сервером, вы можете просто нажать Ctrl-C, чтобы остановить его.


Поздравляем, вы совершили первый большой шаг, чтобы стать веб-разработчиком!


>>> следующая глава >>>

Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 42
  • 0
    Хороший был цикл статей, радует, что автор решил актуальную версию написать. А вам спасибо за перевод.
    • +1
      Что бы написать по русски «Привет, Мир!» потребуется скорректировать
      модуль routes.py
      Добавить строку # -*- coding: utf-8 -*-

      А разве это необходимо? Ведь в третьем питоне строки по умолчанию в юникоде.

      Since Python 3.0, the language features a str type that contain Unicode characters, meaning any string created using «unicode rocks!», 'unicode rocks!', or the triple-quoted string syntax is stored as Unicode.

      The default encoding for Python source code is UTF-8, so you can simply include a Unicode character in a string literal:


      P.S. За перевод спасибо.
      • 0
        Потребуется. Если в тексте скрипта встречаются кириллица
        • 0
          У Девида Бизли на 56 странице… Язык Python позволяет записывать программный код в другой кодировке,
          для чего в первой или во второй строке программы необходимо добавить
          специальный комментарий, указывающий тип кодировки:
          #!/usr/bin/env python
          # -*- coding: UTF-8 -*-
          • +1
            Мы не про другую кодировку говорим.
            А конкретно про utf-8.
            В Python > 3 весь текст по умолчанию в utf-8, и обрабатываться он будет как utf-8.
            Исключение если мы получаем текст из внешнего источника в другой кодировке.
            В том коде что у вас в статье, русские символы обработаются корректно. Если вы не храните исходный код в Windows-1251 например.
            • 0
              Вообщем, как я понимаю, суть в том, что в python 3 utf-8 по умолчанию для типов строк. Во 2-м было два типа: Строковые и юникодные. Для юникодных надо было ставить символ u перед первой кавычкой или encode('utf-8') в конце. Но это не распространяется на кодировку файла. Она может быть любой. Поэтому требуется ее определить при наличии национальных символов в тексте. Ваша фраза >>> В Python > 3 весь текст по умолчанию в utf-8, и обрабатываться он будет как utf-8.… относится к типу строковых переменных, но не к кодировке файлов.

              Там же у Бизли. Исходные тексты программ на языке Python обычно записываются в стандартной 7-битовой кодировке ASCII. Однако пользователи, работающие
              в среде с поддержкой Юникода, могут посчитать это ограничение неудоб-
              ным, особенно когда возникает необходимость в создании большого коли-
              чества строковых литералов с национальными символами.


              Если разобрать, что происходит при запуске программы на python, то мы попадем в модуле site.py в функцию aliasmbcs, где видно, что в случае с виндой и кодировкой все не просто.

              def aliasmbcs():
                  """On Windows, some default encodings are not provided by Python,
                  while they are always available as "mbcs" in each locale. Make
                  them usable by aliasing to "mbcs" in such a case."""
                  if sys.platform == 'win32':
                      import locale, codecs
                      enc = locale.getdefaultlocale()[1]
                      if enc.startswith('cp'):            # "cp***" ?
                          try:
                              codecs.lookup(enc)
                          except LookupError:
                              import encodings
                              encodings._cache[enc] = encodings._unknown
                              encodings.aliases.aliases[enc] = 'mbcs'
              • +1

                Неправильно понимаете, в питоне 3 и строки по умолчанию юникодные, и кодировка файла по умолчанию utf-8 — всё сразу. Писать # -*- coding: utf-8 -*- бессмысленно


                Откройте своего Бизли на странице 772, и увидите там:


                В Python 3 предполагается, что исходные тексты программ набираются в кодировке UTF-8.
                • 0
                  Хотя тут стоит упомянуть потенциальный выстрел в ногу: текстовые файлы открываются на чтение и запись в системной кодировке, которая вовсе не обязательно utf-8. Поэтому в open я всегда прописываю аргумент encoding='utf-8', чтоб на винде проблем не было (а для чтения вообще utf-8-sig, чтобы символ BOM нормально обрабатывался)
                • 0
                  Сейчас посмотрел в доку Python 3 Source Code Encoding

                  Вот что там говорится:
                  By default, Python source files are treated as encoded in UTF-8. In that encoding, characters of most languages in the world can be used simultaneously in string literals, identifiers and comments — although the standard library only uses ASCII characters for identifiers, a convention that any portable code should follow. To display all these characters properly, your editor must recognize that the file is UTF-8, and it must use a font that supports all the characters in the file.


                  Но вот с Windows совсем другое дело, необходимо указывать кодировку, когда она отличная
                  от UTF-8.

                  Тогда надо сделать уточнение, что это касается Windows,
                  а так-же тех случаев когда исходники в отличной от UTF-8 кодировке.

                  • 0
                    Но вот с Windows совсем другое дело, необходимо указывать кодировку.

                    Я не понял, откуда такой вывод? Создал сейчас Python-файл в Блокноте без всяких явных указаний кодировок —


                    всё отлично работает как utf-8

                    • 0
                      Это потому что сам файл сохранен как UFT-8.

                      А теперь проверяем с указанием кодировки Windows-1251 (Linux, Python 3.6.1)

                      SyntaxError: Non-UTF-8 code starting with '\xcf' in file ./main.py on line 1, but no encoding declared;

                      • +1
                        А, я невнимательный, часть «когда она отличная от UTF-8» проглядел, тогда согласен, сорри
            • 0
              Развели дискуссию. По факту, от наличия строки описания кодировки нет минусов. Поэтому, ее наличие приносит исключительно пользу в виду универсальности. Но не является обязательным.
            • 0

              2018 год на дворе, почему сайты на питоне до сих пор не оформляют как полноценные самодостаточные пакеты? Пакет с именем app не загрузишь на PyPI. В данном случае, конечно, достаточно переименовать app во что-нибудь адекватное, но меня расстраивает, что это не делают изначально (джанги это тоже касается, кстати)

              • +1

                Простите, а зачем "сайты на питоне" оформлять как "самодостаточные пакеты" и загружать на PyPl?

                • 0

                  Чтобы другие люди могли легко поднимать их у себя, ваш Капитан Очевидность. Да и деплой упрощается даже без PyPI — копируем whl-файл на сервер, pip install, migrate и в принципе всё

                • 0
                  Сайт это не пакет! Это куча зависимостей причем с учетом провайдера.
                  • 0
                    Это лишь ваше личное мнение. Ничего не мешает сайту быть пакетом. У меня есть два сайта на фласке, опубликованные на PyPI, можете поискать и попробовать запустить у себя если интересно
                    • 0
                      Вне всяких сомнений это мое мнение. Я размышлял над вашим вопросом и просто не нашел такой необходимости оформить сайт на PyPi.

                      Конечно спасибо, посмотрю. Конечно интересно!
                      • 0

                        Нужность загрузки на PyPI действительно спорная (помимо двух упомянутых сайтов у меня есть ещё несколько, которые я не гружу на PyPI, потому что зачем), но тем не менее не вижу смысла не оформлять сайт как пакет изначально, так как пакет удобнее в пользовании (деплой через pip install по-моему намного лучше, чем какой-то убогий git pull) и в будущем передумать будет сильно труднее, чем изначально сделать всё правильно

                        • 0
                          Мне кажется, что если возникает необходимость ЧАСТО разворачивать свой веб-сайт на разных серверах, то pip install git+ssh://git@gitlab.yourcompany.com/user/project@release-1.0.5 гораздо уместнее.
                          • 0
                            Опять же, для этого сайт должен быть оформлен как пакет (setup.py и всё такое)
                  • 0
                    Давайте еще все это завернем в .deb и .rpm, только зачем?
                    Ответ прост: «Потому, что можем!»
                    • 0
                      Действительно, зачем? deb и rpm привязаны к конкретным дистрибутивам и пользы от них мало, а whl ставится куда угодно
                  • 0
                    Если вы используете Microsoft Windows, используйте команду вместо экспорта в команде выше.

                    Саму команду set пропустили.

                    • 0
                      (только учусь, ногами не бейте)
                      virtualenv venv #Создал виртуальную среду
                      venv\Scripts\activate #Активировал, поигрался
                      venv\Scripts\deactivate #Деактивировал
                      Что делать с папкой venv, оставшейся? Её можно просто удалить?
                      • 0
                        Ну, если наигрался, то да! А если собираешься другие части книги делать, то надо оставить.
                        Для того что бы запустить сервер на локальной машине завтра или послезавтра тебе надо активировать виртуальное окружение и выполнить flask run. Без venv\Scripts\activate ничего не выйдет!
                      • 0
                        Пожалуй это самый крутой учебный материал по Flask и Python, который я только видел.

                        Но у меня несколько отвелечённый вопрос — может быть кто-нибудь знает что-то подобное для PHP и какого-нибудь его фреймворка? Что бы человеку, знающему синтаксис языка, можно было пройти весь путь от проектирования приложения до деплоя.
                      • 0
                        Вопрос, а при изменении содержимого скриптов, сервер сам переопределяет что содержимое скриптов изменилось или надо перезапускать сервер?
                        • 0
                          Надо перезапускать вручную, если значение FLASK_DEBUG=0. В режиме отладки он сам перезапускается. Смотри 7-ю главу
                          следует упомянуть про вторую важную функцию, которая включена в режиме отладки — перезагрузка. Это очень полезная функция разработки, которая автоматически перезапускает приложение при изменении исходного файла. Если вы выполните flask run в режиме отладки, можно продолжать работать в своем приложении и при каждом сохранении файла, приложение перезапустится
                          • 0
                            Спасибо!
                            • 0

                              Что-то вот не перезапускается сервер, если изменять файл шаблона по пути ./app/templates/index.html. Ни export FLASK_DEBUG=1, ни если передать параметр flask run --reload, ни если в ./app/__init__.py прописать app.debug = True не помогают, а изменения в ./app/routes.py, например, отслеживает...

                              • +1

                                Его не нужно перезапускать, фласк сам перечитает шаблон при следующем его использовании. Это можно явно включить или выключить опцией TEMPLATES_AUTO_RELOAD

                        • 0
                          Запутался я тут в трех соснах. :(
                          Непонятно откуда в конце появляется файл microblog.py и каково его назначение?
                          Насколько я понял, приложение создается в __init__.py в строке app = Flask(__name__)
                          У меня получилось запустить сервер только после импорта set FLASK_APP=__init__.py, но фласк ничего не отдает.
                          Если накопипасть все в один файл из мануала на сайте фласка и запустить его напрямую
                          if __name__ == '__main__':
                          app.run(debug=True))
                          то работает.
                          • 0
                            Какая у вас структура каталогов?
                            Посмотрите как устроено здесь

                            Запускать так:
                            (venv) $ export FLASK_APP=microblog.py
                            (venv) $ flask run
                            • 0
                              Жмакаем Ctl+F. Вводим в поле поиска по странице microblog.py и гдето примерно так по середине этой главы находим:
                              Чтобы завершить приложение, вам нужно создать сценарий Python на верхнем уровне, определяющий экземпляр приложения Flask. Давайте назовем этот скрипт microblog.py и определим его как одну строку, которая импортирует экземпляр приложения:

                              from app import app


                              И дальше
                              Чтобы убедиться, что вы все делаете правильно, ниже приведена диаграмма структуры проекта:

                              microblog/
                              venv/
                              app/
                              . __init__.py
                              . routes.py
                              microblog.py

                              Верьте или нет, но первая версия приложения завершена! Прежде чем запускать его, Flask нужно сообщить, как его импортировать, установив переменную среды FLASK_APP:

                              (venv) $ export FLASK_APP=microblog.py
                            • 0
                              Хочу выразить большую благодарность за труд!
                              Также, хочу отметить, что в файле app/__init__.py, в инструкции импорта, лучше вписать точку, вместо явного определения имени текущего каталога (пакета Python), это не будет вызывать взрыв мозга, что откуда берется и будет ясность. Также, если пакет переименуется, то ничего из этого не сломается. т.е, это:

                              from flask import Flask
                              
                              app = Flask(__name__)
                              
                              from app import routes
                              


                              лучше заменить на это:

                              from flask import Flask
                              
                              app = Flask(__name__)
                              
                              from . import routes
                              
                              • 0
                                Может быть! Это к автору… Он отвечает, когда ему пишешь. Возможно эта точка появится в какой то из следующих глав.
                                • 0
                                  Также, хочу отметить, что в файле app/init.py, в инструкции импорта, лучше вписать точку, вместо явного определения имени текущего каталога (пакета Python), это не будет вызывать взрыв мозга, что откуда берется и будет ясность.

                                  Меня учили ровно наоборот: при точке непонятно, откуда это дело импортируется, приходится идти путь к текущему файлу смотреть, отрываясь от кода.


                                  Также, если пакет переименуется, то ничего из этого не сломается

                                  Меня учили ровно наоборот: при переименовании или перемещении точка может замаскировать сломавшиеся импорты, поэтому лучше прописывать всё явно, чтобы на сложных случаях вылетел ImportError, а не непонятно что, когда случайно импортировался другой подмодуль с таким же именем. (Хотя, возможно, к __init__ это не относится, но ведь явное лучше неявного же?)


                                  Не знаю, как часто это всё встречается на практике, но такое мнение тоже есть.

                                  • 0
                                    Меня учили ровно наоборот

                                    Вполне может быть так лучше, как Вас учили.


                                    но ведь явное лучше неявного же?

                                    В том-то и дело, что в этих строчках нужно напрягаться и вспоминать, так как здесь не явно, что действительно Python умеет и может импортировать:


                                    app = Flask(__name__)
                                    from app import routes

                                    На слух это так: из экземпляра app импортровать routes. Если бы пакет (текущий каталог) был бы назван, например как myapp, то у меня бы вопроса не возникло:


                                    app = Flask(__name__)
                                    from myapp import routes

                                    А одна точка (.) — это явное указание, также как и в файловой системе, что импортировать нужно из текущего каталога где этот модуль расположен.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое