Django — Как установить пакет в виртуальное окружение

Содержание

Django — Как установить пакет в виртуальное окружение?

Перед началом работы с Django нам естественно надо установить интерпретатор Python. Подоробнее об этом можно почитать здесь.

Существуют разные способы установки Django. Рассмотрим рекомендуемый способ.

Для установки нам потребуется пакетный менеджер pip . Менеджер pip позволяет загружать пакеты и управлять ими. Нередко, при установке python также устанавливается и менеджер pip. В этом случае мы можем проверить версию менеджера, выполнив в командной строке/терминале следующую команду:

Но если pip не установлен, то мы увидим ошибку типа «pip» не является внутренней или внешней командой, исполняемой программой или пакетным файлом . В этом случае нам надо установить pip.

Для этого нам надо загрузить скрипт https://bootstrap.pypa.io/get-pip.py. Просто перейдем на эту страницу и сохраним все ее содержимое в новый файл get-pip.py . Допустим, данный файл будет сохранен в папку C:\python . Перейдем в папку, где сохранен файл и выполним в командной строке/консоли следующую команду:

Если pip ранее уже был установлен, то можно его обновить с помощью команды

Установка виртуальной среды

Виртуальная среда или virtualenv не является неотъемлимой частью разработки на Django. Однако ее рекомендуется использовать, так как она позволяет создать множество виртуальных сред Python на одной операционной системе. Благодаря виртуальной среде приложение может запускаться независимо от других приложений на Python.

В принципе можно запускать приложения на Django и без виртуальной среды. В этом случае все пакеты Django устанавливаются глобально. Однако что если после создания первого приложения выйдет новая версия Django? Если мы захотим использовать для второго проекта новую версию Django, то из-за глобальной установки пакетов придется обновлять первый проект, который использует старую версию. Это потребует некоторой дополнительной работы по обновлению, так как не всегда соблюдается обратная совместимость между пакетами. Если мы решим использовать для второго проекта старую версию, то мы лишиемся потенциальных преимуществ новой версии. И использование вируальной среды как раз позволяет разграничить пакеты для каждого проекта.

Для работы с виртуальной средой вначале необходимо установить пакет virtualenv с помощью следующей команды

Теперь создадим вируальную среду. Вначале определим каталог для виртуальных сред, где будут располагаться все связанные файлы и папки. Например, пусть это будет каталог C:\virtualenv . Прежде всего перейдем в командной строке/терминале в этот каталог с помощью команды cd. Затем для создания виртуальной среды выполним следующую команду:

Команде virtualenv передается название среды, которая в данном случае будет называться «hello».

После этого в текущей папке будет создан подкаталог hello.

Активация виртуальной среды

Для использования виртуальную среду надо активировать. И каждый раз, когда мы будем работать с проектом Django, связанную с ним виртуальную среду надо активировать. Например, активируем выше созданную среду, которая располагается в текущем каталоге в папке hello. Если наша ОС — Windows, то в папке hello/Scripts/ мы можем найти файл activate.bat , который активирует виртуальную среду. Поэтому для Windows активация виртуальной среды будет выглядеть таким образом:

Для Linux и MacOS активация будет производиться с помощью следующей команды:

После окончания работы с виртуальной средой мы можем ее деактивировать. Для этого в той же папке hello/Scripts/ мы можем найти файл deactivate.bat и таким же образом запустить его.

Установка Django

После активации виртуальной среды для установки Django выполним в консоли следующую команду

Блог на Django #1: Установка Django 2.0

Если Django уже установлен, можете пропустить этот раздел и переходить к части «Создание первого проекта». Django — это пакет Python, поэтому он может быть установлен в любой среде Python. Вот как установить фреймворк для локальной разработки.
Для Django 2.0 обязательны Python 3.4 или старше. Дальше будет использоваться Python 3.6.5. Для Linux или macOS, то Python, вероятно уже установлен. Если Windows — то инструкция по установке здесь.

Проверить установлен ли Python на компьютере можно, введя python в командной строке. Если в ответ отобразится что-то подобное, то Python установлен:

Если он не установлен или установлена версия Python 3.4 или младше, то нужно перейти в раздел “Скачать и установить Python”, найти руководство под свою OS и следовать инструкциям.

Для Python 3 не нужна база данных. Эта версия Python поставляется со встроенной базой данных SQLite. Это облегченная база данных, которая подходит для разработки на Django. Если же нужно будет разворачивать приложение в производственной среде, то понадобится более продвинутое решение: PostgreSQL, MySQL или Oracle. Больше узнать о том, как заставить базу данных работать с Django, можно по этой ссылке: https://docs.djangoproject.com/en/2.0/topics/install/#database-installation.

Создание виртуальной среды Python

Рекомендуется использовать virtualenv для создания виртуальной среды Python так, чтобы можно было спокойно использовать разные версии пакетов для разных проектов. Это практичнее, чем устанавливать пакеты в Python напрямую в систему. Еще одно преимущество virtualenv — для установки пакетов Python не нужны права администратора. Запустите следующую команду в командной строке для установки virtualenv :

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

Это создаст папку my_env вместе со средой Python. Любые библиотеки Python, установленные с активированной виртуальной средой Python, будут установлены в папку my_env/lib/python3.7/site-packages .

Если в системе была предустановлена Python 2.X, а вы установили Python 3.X, то нужно указать virtualenv , чтобы он работал с последней версией.

Можно указать путь, по которому установлен Python 3 и использовать его для создания виртуальной среды с помощью следующих команд:

Используйте следующую команду для активации виртуальной среды:

Часть 1. Python/Django и Hello World. Запуск тестового сайта на Python/Django под OS Windows.

�� 1 237 просмотров

Django — это MVC/MTV — фреймворк, написанный на языке Python, а Python — высокоуровневый язык для всех повседневных задач на любой платформе и имеет интерпретаторы для всех известных ОС, есть даже реализация для запуска поверх Java — машины, которая именуется , как Jython.

О чем будет статья?

В статье затронем моменты установки интерпретатора Python 3.x и Django на Windows, в целях запуска тестового сайта на Python на ОС Windows. Обычно, при разработке проекта приходиться писать код на десктопе, чем и служит для нас Windows, а конечный вариант грузить на сервер, где правит только командная строка Linux — системы.

Установка Python и PIP на Windows

Для установки переходим на официальный сайт разработчика. Наводим курсором на раздел «Downloads» и видим всплывающее табло

На момент написания данной статьи поддерживаются 2 версии языка — 2.x и 3.x. Так как на версии 2.x написано очень много проектов и версии языка отличаются друг от друга кардинально, то поддерживаются обе версии, но в новых проектах предпочтительнее использовать последнюю версию языка — 3.x. Загружаем и кликаем для установки. Установка Python 3.x идет стандартным образом

На начальном этапе установки необходимо указать, что мы хотим добавить нашу программу в переменную среду Windows, чтобы выполнять команды Python через командную строку. Если данный пункт отсутствует на интсалляторе, то придется добавить вручную через панель настроек Windows, прописав через «;» путь установки Python для переменной PATH. Инсталлятор предлагает по умолчанию установить Python в папку пользователя системы. Нажмем пользовательский режим, оставляем все, как есть и принимаем во внимание, что pip устанавливается в процессе инсталляции Python и если в инсталляторе его нет, придется установить после установки Python.

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

Жмем «Next» и меняем место установки. Можно установить в любое удобное место — все на вкус и удобство пользователя. Жмем «Install» и заканчиваем установку.

Если в командной строке выскакивает сообщение, что есть более новая версия pip и, вместе с инсталлятором установилась старая версия, то проблему решит апгрейд pip через команду:

Если pip не установлен при инсталляции, то давайте разберем другой способ установки pip. Другой способ установки инструмента pip — скачиваем этот инструмент get-pip.py с официального сайта и запускаем этот файл через командную строку

После установки надо добавить переменную C:\PythonServer\Lib\site-packages\django\bin в PATH к уже имеющимся переменным Python, которые были добавлены автоматически инсталлятором

Установка Django в виртуальной среде Windows

После того, как Python и pip установлены и настроены переменные среды, необходимо установить пакеты Django. Есть несколько способов установки Django. В данной статье будем пользоваться рекомендованным методом установки официального релиза Django.

Ниже показан рекомендованный метод установки Django от разработчиков этого фреймворка:

  1. Установка через pip. Так как pip был установлен через автономный инсталлятор, то необходимо проверить на то, что он имеет последнюю, актуальную версию, иначе это может быть причиной сбоя установки.
  2. Использование virtualenv и virtualenvwrapper. Эти инструменты предоставляют изолированные среды Python, которые являются более практичными, чем устанавливаемые пакеты в системе. Они , также, позволяют устанавливать пакеты без привилегий администратора. Здесь дополнительная информация по созданию и использованию virtualenv на Python 3.
  3. После создания и активации виртуальной среды, нужно установить Django через команду

Теперь необходимо выполнить каждый из вышеизложенных шагов последовательно.

  1. Так как pip был у нас установлен в процессе инсталляции, то пропускаем этот шаг.
  2. Устанавливаем виртуальную среду через установщик pip при помощи последовательности команд:

и проверяем версию установленного virtualenv:

Итак, в предыдущем шаге мы установили инструмент для создания виртуальных сред Python. Настал момент создания виртуальной среды. Виртуальную среду можно создать в любом месте. Для нашего примера создадим в корневой папке Python C:\PythonServer\ новую папку Environments, в которой будут создаваться наши новые среды. Теперь в этой папке создадим новую виртуальную среду под названием «sites» и для этого, через командную строку заходим в папку C:\PythonServer\Environments и выполняем команду:

И после того, когда виртуальная среда создана, через командную строку заходим в папку созданной виртуальной среды:

и активируем эту среду при помощи команды:

и выполняем команду:

которая вернет версию скрипта

Для деактивации текущей среды или выхода из текущей среды необходимо, из папки текущей среды, выполнить команду:

После того, как создали виртуальную среду и активировали нам необходимо установить в эту виртуальную среду фреймворк Django:

Далее заходим в папку нашей среды и устанавливаем через .\Scripts\django-admin.py исходники нашего проекта через команду:

или то же самое можно сделать через команду, которая работает через виртуальную среду:

где mathzilla — это название моего проекта. После выполнения этой команды в корневой папке нашей среды sites будет создана новая папка mathzilla с исходниками нашего начального проекта и осталось его запустить.
В Django, внутри проекта может содержаться приложения и по сути дела, любой проект Django — это сборка мелких отдельных приложений, которые, как кирпичики служат для всей работоспособной системы. Для создания приложения внутри проекта необходимо зайти внутрь папки проекта и запустить команду:

или, то же самое можно сделать командой:

Для запуска проекта переходим в папку нашего проекта выполняем команду запуска сервера при помощи файла manage.py:

и пойдет процесс запуска сервера с указанием локальной ссылки и порта, по которому у нас доступен наш тестовый сайт на Django. В моем случае сервер запустился по ссылке:

На этом установка Python и тестового сервера с Django завершена.

Развертывание приложения на Django с uWSGI и nginx в производственной среде

Это небольшое руководство предназначено для пользователя Django, который хочет настроить приложение Django c веб-сервером в производственной среде. В нем описаны шаги, необходимые для настройки приложения на Django, чтобы оно хорошо работало с uWSGI и nginx.

Концепция

Веб-сервер может обслуживать статичные файлы (HTML, изображения, CSS и т. д.) напрямую из файловой системы. Но он не может напрямую общаться с приложением на Django. Для этого ему нужно что-то, что будет запускать приложение, отправлять запросы от веб-клиентов (браузеров) и возвращать ответы. Для этого создан Web Server Gateway InterfaceWSGI. WSGI – это спецификация, которая описывает, как веб-сервер взаимодействует с веб-приложениями и как веб-приложения могут быть объединены в цепочку для обработки одного запроса.

uWSGI – это одна из реализаций WSGI в Python. В этом руководстве мы настроим uWSGI таким образом, чтобы он создавал сокет или порт и обслуживал запросы/ответы веб-сервера по протоколу uwsgi. В итоге наш полный стек компонентов будет выглядеть так:

Прежде чем начать настройку uWSGI

virtualenv

Убедитесь, что вы используете virtualenv, если нет его нужно установить (позже мы опишем, как установить общесистемный uwsgi):

Django

Установите Django в свой virtualenv, создайте новый проект и перейдите в проект:

О домене и о порте

В этом статье мы назовем наш домен example.com. Замените это доменное имя на свое полное доменное имя или IP-адрес.

Повсеместно, мы будем использовать порт 8000 для публикации на веб-сервере, так же, как сервер запуска Django делает это по умолчанию. Конечно, вы можете использовать любой порт, который хотите, но я выбрал этот, чтобы он не конфликтовал с тем, что веб-сервер уже может делать.

Базовая установка и настройка uWSGI

Установите uWSGI в свой virtualenv

Конечно, есть и другие способы установки uWSGI, но этот так же хорош, как и любой другой. Помните, что вам нужно будет установить пакеты разработки Python. В случае Debian или систем, производных от Debian, таких как Ubuntu, вам нужно установить pythonX.Y-dev, где X.Y – ваша версия Python.

Базовый тест

Создайте файл с названием test.py:

Примечание

Учтите, что Python 3 требует bytes().

Запуск uWSGI:

Эти опции означают:

  • http :8000 : использовать протокол http и порт 8000
  • wsgi-file test.py : загружаем файл test.py

При обращение через браузере к http://example.com:8000 вы должны сообщение «Hello World».

Теперь наш стек компонентов выглядит следующим образом:

Протестируем проект Django

Теперь мы хотим, чтобы uWSGI делал то же самое, но вместо приложения test.py запускал сайт на Django.

Если вы еще этого не сделали, убедитесь, что ваш проект на Django действительно работает:

И далее запустите его с помощью uWSGI:

  • modulemysite.wsgi: означает загрузку указанный модуля wsgi

Если теперь зайти через браузер на сервер должно отобразиться приложение а наш стек компонентом будет таким:

Но как правило, браузер не должен напрямую обращаться к uWSGI. Это работа для веб-сервера, который будет действовать как посредник.

Основы nginx

Установка nginx

После установки проверьте, работает ли nginx, посетив страницу по умолчанию в веб-браузере по порту 80 – вы должны получить сообщение от nginx: «Welcome to nginx!». В этом случае наш стек будет таким:

Настройте nginx для своего сайта

Далее вы можете использовать файл uwsgi_params, который доступен в каталоге nginx дистрибутива uWSGI или по адресу https://github.com/nginx/nginx/blob/master/conf/uwsgi_params

Скопируйте его в каталог вашего проекта. Далее мы укажем nginx как его использовать.

Теперь создайте файл с именем mysite_nginx.conf со следующим содержимым:

В этом файле мы указали nginx обслуживать мультимедийные и статические файлы из файловой системы, а также обрабатывать запросы, предназначенные для Django. При развертывание больших систем считается хорошей практикой разрешать одному серверу обрабатывать статические/мультимедийные файлы, а другому – приложения Django.

Создайте ссылку на этот файл в /etc/nginx/sites-enabled, чтобы nginx смог его увидеть:

Развертывание статических файлов

Перед запуском nginx вы должны собрать все статические файлы Django в папке со статикой. Для этого вы должны отредактировать mysite/settings.py, добавив в него:

а потом запустить

Базовый тест nginx

Чтобы проверить, что медиа-файлы обслуживаются правильно, добавьте изображение с именем media.png в каталог /path/to/your/project/project/media, а затем посетите http://example.com:8000/media/media.png – если это работает, вы будете знать, по крайней мере, что nginx правильно обслуживает файлы.

nginx и uWSGI и test.py

Давайте еще раз запустим приложение «hello world» test.py.

Это почти так же, как и раньше, за исключением того, что один из вариантов отличается:

  • socket :8001 : использует протокол uwsgi, порт 8001

В то же время nginx настроен на связь с uWSGI через этот порт и с внешним миром через порт 8000. Посетите:

Теперь наш стек будет следующим:

Между тем, вы можете попытаться взглянуть на вывод uswgi по адресу http://example.com:8001 – но вполне вероятно, что он не будет работать, потому что ваш браузер работает по протоколу http, а не через протокол uWSGI, хотя вы должны увидеть вывод uWSGI в терминале.

Использование Unix-сокетов вместо портов

До сих пор мы использовали порты TCP, потому что это проще, но на самом деле лучше использовать сокеты Unix, – так как в этом случае будет меньше накладных расходов.

Отредактируйте mysite_nginx.conf, изменив следующее:

и перезапустите nginx.

Запустите uWSGI снова:

На этот раз опция socket сообщает uWSGI, какой файл сокетов использовать.

Если это не работает

Проверьте ваш журнал ошибок nginx (/var/log/nginx/error.log). Если вы видите что-то вроде:

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

В этом случае попробуйте следующую команду:

Возможно, вам также придется добавить своего пользователя в группу nginx (которая, вероятно, относится к www-data) или наоборот, чтобы nginx мог правильно читать и записывать в ваш сокет.

Запуск приложения Django с помощью uwsgi и nginx

Давайте теперь запустим наше приложение Django:

Теперь uWSGI и nginx должны обслуживать не просто модуль «Hello World», а ваш проект Django.

Настройка uWSGI для работы с INI-файлом

Мы можем поместить в файл те же параметры, которые мы использовали с uWSGI, а затем попросить uWSGI запуститься с этим файлом.

Создайте файл с именем mysite_uwsgi.ini:

И запустите uwsgi, используя этот файл:

Еще раз, проверьте, что сайт Django работает, как ожидалось.

Установите uWSGI для всей системы

Пока у нас uWSGI был установлен только в нашей виртуальной среде; иногда может возникнуть, чтобы он был установлен в масштабе всей системы.

и установите uWSGI для всей системы:

Вики uWSGI описывает несколько процедур установки (installation procedures). Перед установкой uWSGI для всей системы стоит подумать, какую версию выбрать и какой подходящий способ ее установки.

Проверьте еще раз, что вы все еще можете запускать uWSGI так же, как и раньше:

Режим Emperor

uWSGI может работать в режиме «emperor». В этом режиме он следит за каталогом конфигурационных файлов uWSGI и порождает экземпляры («vassals») для каждого найденного файла.

Всякий раз, когда в конфигурационный файл вносятся изменения, emperor автоматически перезапускает vassal.

Вам может потребоваться запустить uWSGI с помощью sudo:

Эти опции означают:

  • emperor : каталог где искать vassals (конфигурационные файлы)
  • uid : идентификатор пользователя user id процесса после его запуска
  • gid : идентификатор группы group id процесса после его запуска

Запуск uWSGI при загрузке системы

Последний шаг – это сделать автоматический запуск uWSGI во время запуска системы.

12. Виртуальное окружение и пакеты

12.1. Введение

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

Это означает, что может отсутствовать возможность для одной установки Python удовлетворить требования каждого приложения. Если приложению A нужна версия 1.0 конкретного модуля, но приложение B нуждается в версии 2.0, то требования конфликтуют и установка любой версии 1.0 или 2.0 оставит одно приложении неспособным запуститься.

Решением этой проблемы является создание virtual environment (docs.python.org/3/glossary.html#term-virtual-environment), автономного дерева директорий, которое содержит инсталляцию Python для конкретной версии Python, плюс ряд дополнительных пакетов.

Различные приложения могут потом использовать разные виртуальные окружения (virtual environments). В примере выше, чтобы разрешить конфликт требований, приложение A может иметь свою собственную виртуальную среду с установленной версией 1.0, в то время как у приложения B будет другое виртуальное окружение с версией 2.0. Если B требует библиотеку, которая должна быть обновлена до версии 3.0, это не касается окружения приложения A.

12.2. Создание виртуального окружения

Модуль, используемый для создания и управления виртуальными средами, называется venv (docs.python.org/3/library/venv.html#module-venv). Он обычно будет установлен большинством новых версий Python, которые вам доступны. Если вы имеете разные версии Python в вашей системы, то можете выбрать конкретную версию Python, выполнив команду python3 или какую версию захотите.

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

Это создаст каталог tutorial-env, если он не существует, и также создаст директории внутри него, содержащие копию интерпретатора Python, стандартную библиотеку и различные вспомогательные файлы.

Создав виртуальную среду, вы можете ее активировать.

В Windows командой:

В Unix или MacOS:

(Этот скрипт записан для оболочки bash. Если вы используете оболочки csh или fish, вместо этого вам следует использовать альтернативные скрипты activate.csh и activate.fish .)

Активация виртуального окружения изменит приглашение оболочки, показывая, что вы используете виртуальную среду, и изменит среду так, что запуск python даст вам конкретную версию и установку Python. Например:

12.3. Управление пакетами с помощью pip

Вы можете устанавливать, обновлять и удалять пакеты, используя программу под названием pip. По умолчанию pip будет устанавливать пакеты из Индекса пакетов Python. Вы можете просматривать Python Packege Index с помощью браузера или можете использовать ограниченную функцию поиска pip :

У pip есть ряд подкоманд: «search», «install», «freeze» и др. (Проконсультируйтесь с руководством Installing Python Modules (docs.python.org/3/installing/index.html#installing-index) для полной документации для pip .)

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

Также вы можете установить конкретную версию пакета, задав имя пакета с последующим == и номером версии:

Если вы перезапустите эту команду, pip заметит, что требуемая версия уже установлена и ничего не сделает. Вы можете указать другой номер версии, чтобы получить эту версию, или можете запустить pip install —upgrade для обновления пакета до последней версии:

pip uninstall с последующим одним или более именами пакетов удалит пакеты из виртуального окружения.

pip show выведет информацию о конкретном пакете:

pip list выведет все пакеты, установленные в виртуальном окружении:

10 основных ошибок, совершаемых Django-разработчиками

В этом руководстве мы рассмотрим основные ошибки Django-разработчиков и узнаем, как их избежать. Статья может быть полезна даже опытным разработчикам, потому что и они совершают такие ошибки, как поддержка неподъёмно больших настроек или конфликтов имён в статических ресурсах.

Django — бесплатный сетевой open source Python-фреймворк, помогающий решать распространённые в разработке проблемы. Он позволяет создавать гибкие, хорошо структурированные приложения. В Django уже из коробки есть много современных возможностей. Например, для меня такие фичи, как Admin, инструмент Object Relational Mapping (ORM), Routing и Templating, делают Django первым кандидатом при выборе инструментария для разработки. Создание приложения требует много сил, и, наслаждаясь своим делом, как и любой разработчик, я хочу тратить как можно меньше времени на рутинные задачи. Django сильно в этом помогает, не заставляя жертвовать гибкостью приложения.

Киллер-фича Django — мощный конфигурируемый админский интерфейс, который автоматически (автомагически?) генерируется на основе схемы вашей модели и моделей админки. Чувствуешь себя прямо-таки волшебником. С помощью интерфейса Admin пользователь может конфигурировать много вещей, в их числе — список управления доступом (access control list, ACL), разрешения и действия на уровне строк (row-level), фильтры, порядки сортировки (orders), виджеты, формы, дополнительные URL-хелперы и многое другое. Я считаю, что админка нужна каждому приложению. Это лишь вопрос времени, когда такая панель понадобится вашему основному приложению. В Django она создаётся быстро и удобно.

Также в Django есть мощная ORM, из коробки работающая со всеми главными базами данных. Она «ленива»: в отличие от других ORM, обращается к БД только по мере необходимости. В ней есть поддержка основных SQL-инструкций (и функций), которые вы можете использовать из своего исходного Python-кода наряду со всеми остальными возможностями языка.
В Django очень гибкий и мощный шаблонизатор (templating engine). Доступны многие стандартные фильтры и метки (tags), также можно создавать свои собственные. Django поддерживает другие движки как собственные шаблоны, предоставляет API для лёгкой интеграции с другими движками посредством стандартных shortcut-функций для обработки шаблонов.

Фреймворк имеет и много других важных возможностей вроде URL-роутера, который парсит входящие запросы и генерирует новые URL на основе схемы роутинга. В целом Django приятен в работе, и, когда вам понадобится помощь, просто почитайте документацию.

Ошибка № 1. Использование для проектных зависимостей глобального окружения Python

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

Обычно такую ошибку допускают новички в Python- и Django-разработке, не знающие об особенностях изоляции окружения Python.

Есть много способов изолировать окружение, наиболее часто встречаются такие:

  • virtualenv: пакет Python, генерирующий папку с окружением. Содержит скрипт для (де)активации окружения и управления установленными в нём пакетами. Это мой любимый и самый простой метод. Обычно я создаю окружение поближе к папке проекта.
  • virtualenvwrapper: пакет Python, глобально устанавливающий набор инструментов для создания/удаления/активации и т. д. виртуальных окружений и предоставляющий доступ к этому набору. Все окружения хранятся в одной папке (её можно переписать с помощью переменной WORKON_HOME). Я не вижу преимуществ в использовании virtualenvwrapper вместо virtualenv .
  • Виртуальные машины: нет лучшей изоляции, чем целая виртуальная машина, выделенная под ваше приложение. Есть масса доступных инструментов, например VirtualBox (бесплатный), VMware, Parallels и Proxmox (мой фаворит, есть бесплатная версия). В сочетании с инструментом автоматизации виртуальных машин вроде Vagrant это может оказаться очень мощным решением.
  • Контейнеры: в последние годы я почти в каждом проекте использую Docker, особенно в новых проектах, начинаемых с нуля. Docker — невероятный инструмент с множеством возможностей. Для его автоматизации доступна куча сторонних инструментов. В Docker есть кеширование уровней (layer caching), позволяющее крайне быстро пересоздавать контейнеры. В них я использую глобальное окружение Python, потому что каждый контейнер имеет собственную файловую систему и проекты изолируются на высоком уровне. Docker позволяет новым членам команды быстрее начинать работу над проектом, особенно если у них есть опыт работы с этой технологией.

Ошибка № 2. Отсутствие привязки зависимостей в файле requirements.txt

Каждый новый проект Python должен начинаться с файла requirements.txt и нового изолированного окружения. Обычно вы с помощью pip/easy_install устанавливаете все пакеты, не забывая о requirements.txt . Обычно проще (возможно, правильнее) развёртывать проекты на серверах или на машинах членов команды.

Также важно в файле requirements.txt выполнять привязку (pin) конкретных версий ваших зависимостей. Обычно разные версии пакета предоставляют разные модули, функции и параметры функций. Даже в младших версиях изменения зависимостей могут оказаться такими, что это сломает ваш пакет. Это очень серьёзная проблема, если у вас живой проект и вы планируете регулярно его развёртывать, так как без системы управления версиями ваша сборочная система всегда будет устанавливать последнюю доступную версию пакета.

В production всегда выполняйте привязку пакетов! Я для этого использую очень хороший инструмент pip-tools. Он предоставляет набор команд, помогающих управлять зависимостями. Инструмент автоматически генерирует requirements.txt , в котором привязаны не просто ваши зависимости, а вообще всё дерево, т. е. и зависимости ваших зависимостей.

Иногда нужно обновить какие-то пакеты в списке зависимостей (например, только фреймворк или утилиту). Если вы прибегаете к pip freeze, то не знаете, какие зависимости используются какими пакетами, и поэтому не можете их обновить. Инструмент pip-tools автоматически привязывает пакеты в соответствии с привязанными вами зависимостями, и поэтому он автоматически решает, какие пакеты нужно обновить. А благодаря используемым комментариям в requirements.txt вы всегда знаете, какой пакет пришёл из какой зависимости.

Если быть ещё более осторожным, то можно делать бекап исходных файлов ваших зависимостей. Храните копию в своей файловой системе, Git-папке, S3-папке, FTP, SFTP — где угодно, лишь бы под рукой. Бывают ситуации, когда исключение из списка относительно небольшого пакета ломает большое количество пакетов в npm. Pip позволяет скачивать все необходимые зависимости в виде исходных файлов. Почитайте об этом подробнее, выполнив команду pip help download .

Ошибка № 3. Использование старомодных Python-функций вместо представлений-классов (Class-based Views)

Иногда целесообразно использовать в файле приложения views.py маленькие Python-функции, особенно для тестовых или утилитарных представлений. Но обычно в приложениях нужно использовать представления на основе классов (CBV).

CBV — это представления общего назначения, предоставляющие абстрактные классы, реализующие распространённые задачи веб-разработки. CBV созданы профессионалами и покрывают большинство востребованных моделей поведения. У них есть прекрасно структурированный API, и CBV подарят вам возможность наслаждаться всеми преимуществами ООП. Ваш код будет чище и читабельнее. Забудьте о трудностях использования стандартных функций представления (view functions) Django для создания списков, CRUD-операций, обработки форм и т. д. Можно просто расширять подходящий CBV под ваше представление и переопределять (override) функции или свойства класса, конфигурирующие поведение представления (обычно функция возвращает свойство, и вы можете добавить в неё любую логику, которая способна превратить ваш код в спагетти, если вместо CBV вы прибегнете к функциям представления).

Например, можно использовать в проекте разные миксины, которые переопределяют основные модели поведения CBV: создание контекстов представлений, проверка авторизации на уровне строк (on the row level), автосоздание путей шаблонов на основе структур приложения, интегрирование умного кеширования и многое другое.

Я создал пакет Django Template Names, который стандартизирует имена шаблонов для ваших представлений на основе имени приложения и имени класса представления. Я пользуюсь им каждый день и экономлю кучу времени при выборе имён. Просто вставьте миксин в свой CBV — class Detail(TemplateNames, DetailView): — и он начнёт работать! Конечно, можете переопределить мои функции и добавить мобильные адаптивные шаблоны, другие шаблоны для user-agent’ов или что-нибудь ещё.

Ошибка № 4. Написание «толстых» (fat) представлений и «тонких» (skinny) моделей

Если у вас логика приложения перенесена из модели в представления, это означает, что в представлениях находится код, принадлежащий модели. То есть представления становятся «толстыми», а модель — «тонкой».

А нужно писать «толстые» модели и «тонкие» представления.

Разбейте логику по маленьким методам в модели. Это позволит использовать их многократно и из многочисленных источников (админский пользовательский интерфейс, пользовательский интерфейс фронтенда, конечные точки API, многочисленные представления). Это займёт всего несколько строк кода, и вам не придётся копипастить кучу строк. Когда в следующий раз будете писать функциональность отправки письма пользователю, расширьте модель с помощью email-функции, а не пишите логику в контроллере.

Это сделает ваш код более удобным для модульного тестирования, потому что вы сможете протестировать логику электронной почты в одном месте, а не делать это в каждом контроллере. Подробнее об этой проблеме почитайте в Django Best Practices. Решение простое: пишите «толстые» модели и «тонкие» представления. Начните это делать уже в следующем проекте или рефакторьте текущий.

Ошибка № 5. Огромный, неповоротливый файл настроек

Даже в новом файле настроек Django-проекта этих настроек содержится множество. А в реальных проектах файл разрастается до 700+ строк, которые трудно сопровождать, особенно когда окружениям разработки, продакшена и стейджинга нужны разные конфигурации.

Вы можете вручную разделить конфигурационный файл и создать отдельные загрузчики, но я хочу порекомендовать отличный, хорошо протестированный Python-пакет Django Split Settings, соавтором которого я являюсь.

Пакет предоставляет две функции — optional и include , которые поддерживают подстановки (wildcards) для путей и импортируют ваши конфигурационные файлы в тот же контекст. Благодаря этому можно просто создавать конфигурации с помощью объявления конфигурационных записей в ранее загруженных файлах. Пакет никак не влияет на производительность Django и может применяться в любых проектах.

Вот пример минимальной конфигурации:

Ошибка № 6. Приложение всё-в-одном, плохая структура приложения и некорректное размещение ресурсов

Любой Django-проект состоит из нескольких приложений. В терминологии Django приложение — это Python-проект, содержащий как минимум файлы __init__.py и models.py . В последних версиях Django models.py больше не нужен, достаточно только __init__.py .

Django-приложения могут содержать Python-модули, характерные для Django модули (представления, URL’ы, модели, админскую панель, формы, метки шаблонов и т. д.), статичные файлы, шаблоны, миграции базы данных, команды управления, модульные тесты и пр. Нужно разбивать своё монолитное приложение на маленькие многократно используемые приложения с простой логикой.

У вас должна быть возможность полностью описать назначение приложения одним-двумя короткими предложениями. Например: «Позволяет пользователю зарегистрировать и активировать по почте свой аккаунт».

Рекомендуется назвать папку проекта project и положить приложения в project/apps/ . Затем положить все зависимости приложений в собственные подпапки.

  • Статичные файлы: project/apps/appname/static/appname/
  • Метки шаблона: project/apps/appname/templatetags/appname.py
  • Файлы шаблона: project/apps/appname/templates/appname/

Всегда добавляйте имена приложений в виде префиксов в названия подпапок, потому что все статические папки объединяются в одну. И если два или более приложений имеют файл js/core.js , то последнее приложение в settings.INSTALLED_APPLICATIONS переопределит все предыдущие. Однажды я столкнулся с таким багом в своём проекте и потратил около шести часов на отладку, пока не сообразил, что другой разработчик переопределил мой static/admin/js/core.js , потому члены команды реализовали кастомную админскую SPA-панель и дали своим файлам такие же имена.

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

Благодаря такой структуре вы можете в любой момент экспортировать приложение в другой Python-пакет и снова его использовать. Можете даже опубликовать его в PyPi в качестве open source пакета или переместить в другую папку. У вас получится примерно такая структура проекта:

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

Ошибка № 7. STATICFILES_DIRS и STATIC_ROOT смущают новичков в Django-разработке

Статичные файлы — это ресурсы (assets), которые не меняются по мере использования приложения. Например, JavaScript, CSS, изображения, шрифты и т. д. В Django они «накапливаются» в публичной директории в ходе развёртывания.

В режиме разработки — python manage.py runserver — Django ищет статичные файлы с помощью настройки STATICFILES_FINDERS. По умолчанию он пытается найти запрошенный файл в папках, перечисленных в STATICFILES_DIRS. Если не находит, то ищет с помощью django.contrib.staticfiles.finders.AppDirectoriesFinder , которая проверяет папку static каждого установленного в проекте приложения. Такая схема позволяет писать многократно используемые приложения, поставляемые со своими собственными статичными файлами.

В production вы раздаёте статичные данные посредством отдельного веб-сервера, например nginx. Он ничего не знает о структуре приложений проекта Django или о том, по каким папкам распределены ваши статичные файлы. К счастью, Django предоставляет нам команду управления сбором статичных данных (collect static management command) — python manage.py collectstatic , которая проходит по STATICFILES_FINDERS и копирует все статичные файлы из папок static приложений, а также из папок, перечисленных в STATICFILES_DIRS , в заданную вами в STATIC_ROOT директорию. Это позволяет разрешать (resolution) ресурсы в виде статичных данных с помощью той же логики, что и у Django-сервера в режиме разработки, и собирать в одном месте для веб-сервера все статичные файлы.

Не забудьте выполнить collectstatic в вашем production-окружении!

Ошибка № 8. Использование в production STATICFILES_STORAGE по умолчанию и загрузчиков Django-шаблонов

Давайте поговорим об управлении ресурсами (asset) production-окружения. Мы можем обеспечить наилучший UX, если воспользуемся политикой «у ресурсов не истекает срок действия» (assets never expire) (подробнее о ней можно почитать здесь). Это означает, что все наши статичные файлы должны быть закешированы браузерами на недели, месяцы или даже годы. Иными словами, пользователи должны лишь единожды скачивать ресурсы!

Классная идея, и её можно реализовать всего в несколько строк в nginx-конфигурации для нашей папки со статичными файлами. Но что насчёт проверки актуальности кеша? Если пользователь лишь один раз скачивает наш ресурс, то что делать в том случае, если вы обновите логотип, шрифты, JavaScript или цвет текста в меню? Для решения этой задачи вам нужно при каждом развёртывании генерировать уникальные URL’ы и имена для каждого статичного файла!

Для этого можно использовать ManifestStaticFilesStorage в качестве STATICFILES_STORAGE (будьте осторожны, хеширование включается только в режиме DEBUG=false ) и выполнить команду collectstatic . Это приведёт к снижению количества запросов ресурсов у вашего production-сайта и сделает его отрисовку гораздо быстрее.

Клёвая фича Django — закешированный загрузчик шаблона. Он не перезагружается и парсит файлы шаблона при каждой его отрисовке. Парсинг шаблона — очень дорогая операция, она требует много вычислительных ресурсов. По умолчанию Django-шаблоны парсятся при каждом запросе, а это плохо, особенно в production, где за короткий промежуток времени могут обрабатываться тысячи запросов.

В разделе конфигурации cached.Loader можно найти хороший пример и подробности решения проблемы. Не используйте загрузчик в режиме разработки, потому что он не перезагружает отпарсенные шаблоны из файловой системы. Вам понадобится перезапускать свой проект, используя python manage.py startapp , при каждом изменении шаблона. При разработке это может раздражать, зато идеально для production-окружения.

Ошибка № 9. Чистый Python для утилит или скриптов

У Django есть отличная фича — команды управления. Используйте их вместо изобретения велосипеда в виде написания скриптов на чистом Python для утилит вашего проекта.

Также обратите внимание на пакет Django Extensions, представляющий собой коллекцию кастомных расширений для Django. Возможно, кто-то уже реализовал ваши команды! Существует много распространённых целевых команд.

Ошибка № 10. Велосипедостроение

Для Django и Python есть тысячи готовых решений. Обратитесь к поисковикам, прежде чем писать что-то, что вовсе не уникально. Вероятно, уже есть подходящее решение.

Не надо усложнять. Сначала — гуглим! Установите найденный качественный пакет, сконфигурируйте, расширьте и интегрируйте в свой проект. И если есть возможность, внесите свой вклад в open source.

Вот вам для начала список моих собственных пакетов для Django:

  • Django Macros URL: с помощью макросов облегчает написание (и чтение) URL-паттернов в Django-приложениях.
  • Django Templates Names: маленький миксин, помогает легко стандартизировать имена ваших CBV-шаблонов.
  • Django Split Settings: позволяет распределить Django-настройки по нескольким файлам и директориям. Легко переопределяет и модифицирует настройки. Использует подстановки (wildcards) в путях файлов и помечает файлы настроек как опциональные.

Don’t repeat yourself (DRY)!

Я сторонник DRY-концепции, поэтому создал Django skeleton — удобный инструмент с рядом приятных функций уже из коробки:

  • Docker-образы для разработки/production, управляемые docker-compose, что позволяет легко оркестрировать списком контейнеров.
  • Простой Fabric-скрипт для развёртывания в production.
  • Конфигурация для пакета Django Split Settings с настройками базы и локальных источников.
  • Интегрированный в проект Webpack — при выполнении команды collectstatic Django соберёт только папку dist.
  • Сконфигурированы все основные Django-настройки и фичи вроде кешируемых в production Django-шаблонов, хешированных статичных файлов, интегрированного тулбара для отладки, журналирования и т. д.

Это готовый к использованию Django-скелет для вашего следующего проекта, создаваемого с нуля. Надеюсь, он сэкономит вам кучу времени. Webpack имеет минимальную базовую конфигурацию, но также в него с помощью SASS установлены заранее сконфигурированные для обработки файлы .scss.

Django Fan

Установка virtualenv

    Опубликовано: Теги: администрирование

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

Благодаря virtualenv мы можем создавать неограниченное количество изолированных окружений, чтобы работать над разными проектами на рабочей машине или запускать несколько django-сайтов на боевом сервере.

В этом посте будут описаны основные моменты установки виртуального окружения.

Установка virtualenv

Сам инструмент virtualenv устанавливается глобально из PyPi

Если нужна последняя неопубликованная dev-версия, то берем отсюда

Установка нового виртуального окружения

Для создания окружения существует одна основная команда

где ENV — каталог, в котором будет расположено новое виртуальное окружение. При этом как правило создаются:

  • папки ENV/lib/ и ENV/include/ , где находятся вспомогательные файлы; библиотеки виртуального окружения помещаются в ENV/lib/pythonX.X/site-packages/ .
  • ENV/bin , где будет лежать интерпретатор Python. Таким образом, запуск скрипта с шебангом #! /path/to/ENV/bin/python исполнит его в данном виртуальном окружении, а не в системном по умолчанию.
  • Необходимые для дальнейшей работы инструменты pip и setuptools доступны сразу, что позволяет в дальнейшем легко устанавливать другие пакеты, при этом pip запускается из ENV/bin/pip .

Активация окружения

Это добавит в начало $PATH директорию bin/ , делая доступным все ее содержимое, — ничего другого данная команда не делает. После активации в начале приглашения командной строки появится имя окружения в скобках (ENV) $

Если запускать программы непосредственно из этой папки bin/ , тогда даже не потребуется активация. Данная особенность полезна, например, когда мы настраиваем сайты в связке с uwsgi или gunicorn.

Отменить эффект активации можно командой

В Windows создаются соответствующие bat-скрипты с такими же именами.

Удаление окружения

Деактивируем и просто удаляем папку с виртуальным окружением

Некоторые часто используемые опции

Если устанавливать окружение командой virtualenv —system-site-packages ENV , тогда оно сделает доступными все пакеты, установленные глобально. Если вам нужно строго изолировать окружение от глобальной системы, просто не используйте этот флаг.

Если в системе установлено несколько версий Python и вы хотите установить окружение с версией, отличной от версии по умолчанию (например, /usr/bin/python ), то укажите вместо PYTHON полный путь к интерпретатору.

—help — вывод списка всех возможных опций с описанием

Разработка web-приожения на Django(Python)

Как установить Django в Windows

Этот документ поможет вам установить Python 3.5 и Django в Windows. Он также содержит инструкции по установке virtualenv и virtualenvwrapper , которые упрощают работу над проектами Python. Это подразумевается как руководство для начинающих для пользователей, работающих с проектами Django, и не отражает, как Django должен быть установлен при разработке патчей для самого Django.

Шаги в этом руководстве были протестированы с Windows 7, 8 и 10. В других версиях этапы были бы похожи. Вам нужно будет ознакомиться с использованием командной строки Windows.

Установить Python

Django — это веб-инфраструктура Python, что требует установки Python на вашем компьютере. На момент написания статьи Python 3.5 является последней версией.

Чтобы установить Python на свой компьютер, перейдите на страницу https://python.org/downloads/ . Веб-сайт должен предложить вам кнопку загрузки для последней версии Python. Загрузите исполняемый установщик и запустите его. Установите флажок рядом с ним и нажмите . Add Python 3.5 to PATH Install Now

После установки откройте командную строку и убедитесь, что версия Python соответствует версии, установленной вами, выполнив:

О pip

pip — пакет для Python. Это упрощает установку и удаление пакетов Python (таких как Django!). Для остальной части установки мы будем использовать pip для установки пакетов Python из командной строки.

Чтобы установить pip на свой компьютер, перейдите на страницу https://pip.pypa.io/en/latest/installing/ и следуйте инструкциям. Installing with get-pip.py

Установить virtualenv и virtualenvwrapper

virtualenv и virtualenvwrapper предоставляют выделенную среду для каждого проекта Django, который вы создаете. Хотя это и не обязательно, это считается лучшей практикой и сэкономит ваше время в будущем, когда вы будете готовы развернуть свой проект. Просто введите:

Затем создайте виртуальную среду для своего проекта:

Виртуальная среда будет активирована автоматически, и вы увидите «(myproject)» рядом с командной строкой, чтобы обозначить это. Если вы запустите новое командное приглашение, вам нужно снова активировать среду, используя:

Установка Django

Django можно легко установить pip в вашей виртуальной среде.

В командной строке убедитесь, что ваша виртуальная среда активна, и выполните следующую команду:

Это позволит загрузить и установить последнюю версию Django.

По завершении установки вы можете проверить свою установку Django, выполнив ее в командной строке. django-admin —version

Общие подводные камни

Если django-admin отображается только текст справки независимо от того, какие аргументы ему даны, возможно, существует проблема с ассоциацией файлов в Windows. Проверьте, существует ли более чем одна переменная среды для запуска скриптов Python PATH . Обычно это происходит, когда установлена ​​более одной версии Python.

Если вы подключаетесь к интернету за прокси-сервером, может возникнуть проблема при выполнении команды . Задайте переменные среды для конфигурации прокси в командной строке следующим образом: pip install django

Записки разработчика

17.10.2014

Как установить пакет dbfpy в виртуальное окружение virtualenv

Добрый день! Сегодня мы установим пакет Dbfpy в окружение virtualenv.

Думал я как-то импортировать в свое приложение базу КЛАДР. C DBF удобно работать через пакет dbfpy. Поставим:

Этот пакет должен стать через PIP. Если же вы его не нашли, можно попробовать альтернативный способ — воспользоваться утилитой easy_install:

поменяйте версию, если актуальная сменилась.

* (env) — значит, что Вы нужно выполнить команду в виртуальном окружении. Чтобы установить виртуальное окружение:

Развертывание Django проекта на виртуальном хостинге

Недавно перенес оба-два свои блога на WordPress с Петерхоста на Locum. Пока полет нормальный — Locum дешевле, удобней и стабильнее. Также я рекомендовал этот хостинг заказчику для размещения небольшого Django сайта, который я сейчас разрабатываю. О том, как развернуть Django 1.4 проект на виртуальном хостинге Locum.ru, и пойдет речь в этом посте.

Итак, в панели управления создаем новый проект, например, mysite.

Заходим на сервер по SSH и скачиваем последний virtualenv:

1 wget https://raw.github.com/pypa/virtualenv/master/virtualenv.py

Создаем виртуальное Python окружение:

1 python virtualenv.py

/ env /mysite

Флаг —no-site-packages указывать не нужно — теперь это поведение по умолчанию.

/ env / mysite / bin / activate

На локальной машине создаем и редактируем файл зависимостей проекта:

1 pip freeze > req.txt

Заливаем файл на сервер и устанавливаем все необходимые пакеты:

1 pip install -r req.txt

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

Цукерберг рекомендует:  Программирование - Детская веб-студия программирования
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих