Настроить окружение что это

Настраиваем окружение Python с помощью pyenv, virtualenvwrapper, tox и pip-compile

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

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

Python — это язык программирования общего назначения, который часто рекомендуют начинающим. За двадцать лет его существования написано несколько книг по Python. Хотя язык часто называют простым, настройка инструментария Python для разработки далеко не самая простая задача.

Настройка окружения Python достаточно сложна: xkcd

Используйте pyenv для управления версиями

На мой взгляд, это лучший менеджер версий Python. Однако стоит отметить, что pyenv работает на Linux, Mac OS X и WSL2: то есть, трёх «UNIX-подобных» средах.

Установка самого pyenv иногда может оказаться непростой. Но может помочь специальный установщик pyenv, который использует curl | bash для начальной загрузки.

Если вы используете Mac (или другую систему, в которой вы запускаете Homebrew), вы можете прочитать инструкции по установке и использованию pyenv здесь.

После установки и настройки pyenv вы можете использовать pyenv global для установки версии Python по умолчанию. Можете выбрать свою «любимую» версию. Обычно это самая последняя стабильная версия, но это не точно -)

Используйте virtualenvwrapper для настройки виртуального окружения

Для Python можно создавать виртуальные окружения, то есть помещать каждый проект в изолированную среду. Это можно сделать с помощью virtualenvwrapper. Тогда появляется возможность переключаться между виртуальными окружениями в любой момент.

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

Если вам нужно многократно создавать и использовать одно и то же виртуальное окружение, имеет смысл автоматизировать процесс. На сегодняшний день мой выбор — это tox.

Используйте tox для автоматизации

Tox — отличный инструмент для автоматизации ваших тестов. В каждом окружении Python я создаю файл tox.ini. Независимо от того, какую систему я использую для непрерывной интеграции, всё будет работать. И я могу запустить его локально с помощью virtualenvwrapper:

$ workon runner
$ tox

Дело в том, что я тестирую свой код на нескольких версиях Python и нескольких версиях библиотечных зависимостей. Это означает, что tox будет работать в нескольких средах. В некоторых из них будут актуальные зависимости. В некоторых — замороженные. Я мог бы также сгенерировать их локально с помощью pip-compile.

В последнее время я рассматриваю nox как на замену tox. В этой статье я не буду объяснять причины, но вам стоит обратить на него внимание.

Используйте pip-compile для управления зависимостями

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

Для каждого нового проекта я подключаю файл require.in, который (как правило) содержит только один символ:

Да, тут всё правильно. Строка с одной точкой. В файле setup.pyfile для зависимостей я прописываю Twisted> = 17.5 вместо Twisted == 18.1, которая затрудняет обновление до новых версий библиотеки.

«.» означает «текущий каталог», в котором соответствующий файл setup.py используется в качестве источника информации о зависимостях.

Это означает, что при использовании pip-compile requirements.in > requirements.txt будет создан файл с замороженными зависимостями. Вы можете использовать этот файл зависимостей либо в виртуальной среде, созданной virtualenvwrapper, либо в tox.ini.

Иногда может пригодиться файл requirements-dev.txt, сгенерированный из requirements-dev.in (contents: .[dev]) или requirements-test.txt, сгенерированный из requirements-test.in (contents: .[test]).

В качестве альтернативы pip-compile можно использовать dephell. У инструмента dephell есть много интересностей, например, использование асинхронных HTTP-запросов для загрузки зависимостей.

Вывод

Я считаю Python мощным и красивым языком. Тем не менее, чтобы продуктивно работать, я использую определенный набор инструментов, которые доказали свою эффективность, по крайней мере для меня. Поэтому используйте эти четыре инструмента — pyenv, virtualenvwrapper, tox и pip-compile — и будет вам счастье =)

На правах рекламы

Встречайте! Впервые в России — эпичные серверы!
Мощные серверы на базе новейших процессоров AMD EPYC. Частота процессора до 3.4 GHz. Тарифы — от 10 рублей в сутки!

Источник

Рабочее окружение

Настройка рабочего окружения — не такое простое занятие, как может показаться на первый взгляд. Обычно начинающие разработчики (и не только) устанавливают проект и его зависимости прямо на ту систему, где они работают. Этот подход обладает рядом недостатков.

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

Если идет работа с разными проектами, то могут возникать конфликты между окружениями (не совместимые версии, попытка использовать одни и те же порты). Более того, часть сервисов всегда стартует автоматически (базы данных, веб-сервера), и они просто нагружают систему тогда, когда не нужно. Идеальное рабочее окружение соответствует боевой среде (той, куда вы деплоитесь), это не всегда возможно, но на то оно и идеальное.

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

Это настолько распространенный вариант и задача, что появился на свет такой инструмент как Vagrant. По сути, vagrant — это утилита командной строки, которая упрощает управление виртуальными машинами для разработки. То есть сама она не занимается виртуализацией, а требует наличия в системе одного из поддерживаемых средств виртуализации. К ним относятся VirtualBox, Parallels Desktop, VMware Workstation, Docker и даже облачные провайдеры, такие как Amazon EC2. Подход, который предлагает Vagrant, это «виртуальная машина на проект», что правильно, потому что у каждого проекта свое окружение.

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

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

Единый реестр боксов. Вам нужно только указать правильный, а вагрант сам его ставит, настраивает и запускает. Автоматический шаринг директории запуска (обычно это директория с проектом) с виртуальной машиной, то есть код автоматически синхронизируется между хост ОС и гостевой ОС; Легкая настройка проброса портов. Например, вы стартуете сервер внутри вагранта (виртуальной машины), а доступ к нему имеете снаружи.

Provision — это механизм интеграции с различными системами управления конфигурации. Позволяет вам настраивать вагрант посредством, например, ansible. Гибкая и удобная настройка сети. Возможность запускать множество машин под единым управлением. Важно, что вся конфигурация вагранта это файл, который находится под контролем версий внутри проекта. Это означает, что сама настройка пишется один раз и повторно используется всеми членами команды без необходимости повторения всех действий руками каждому.

Чтобы начать работу с Vagrant, сначала необходимо скачать и установить одну из систем виртуализации, например, VirtualBox. Дальше нужно установить сам Vagrant. Установщик можно найти на этой странице https://www.vagrantup.com/downloads.html.

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

Эта команда создаст файл Vagrantfile в директории запуска. Vagrantfile это ruby-скрипт, в котором описывается конфигурация Вагранта. Внутри множество комментариев показывающих то, как можно конфигурировать Вагрант и виртуальную машину. Единственная активированная конфигурация — это указанный box, который будет использоваться. В нашем случае это ubuntu/trusty64 .

Следующая команда запускает виртуальную машину и проводит базовую конфигурацию.

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

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

Еще одной крайне полезной функцией вагранта является проброс портов. Пример:

Теперь все, что запущено на гостевой операционной системе на порту 80, доступно на хост системе на порту 8080. Можно добавить сколько угодно таких пробросов.

Кроме этого, у вагранта есть полезная функциональность под названием Provisioning. Она позволяет интегрироваться с большим количеством систем для управления конфигурацией. Для настройки операционной системы с помощью Ansible достаточно выполнить следующие шаги:

Написать плейбук. Включить provisioning.

Выполнить снаружи команду vagrant provision .

Источник

Мой опыт настройки окружения для Web-разработки

Речь пойдет не о настройке денвера и не о том, как поставить LAMP-стек. Я решил рассказать о том, какое мы в своей команде используем окружение для разработки. Мы разрабатываем Web-сервисы и ERP-системы, но всё это, в сущности, ничто иное, как сайты. Просто сложные внутри и порой не такие красивые снаружи.

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

Подождите, а чем плох денвер?

Основной недостаток денвера состоит в том, что проекты в production не работают на денвере. А значит мы не можем гарантировать, что тщательно отлаженные на компьютере разработчика скрипты не начнут «чудить», когда попадут в production. В production проекты обычно работают в Linux (в нашем случае это CentOS или Amazon Linux). Кроме того, работая на денвере, мы не сможем использовать различные утилиты и средства, которые нам нужны в проекте (например, catdoc, поиск sphinx и многое другое).

Ок, но ведь не все готовы работать в Linux!

Разрабатывать прямо в Linux, конечно круто, но правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере. Поэтому дальше я опишу наш рецепт, как работая в Windows, разрабатывать сайты в Linux.

Мы используем CentOS 7, но думаю, без существенных изменений все будет работать и на других дистрибутивах.

Создаем образ виртуальной машины

Ок. Первое, что нужно сделать — это поставить на компьютер гипервизор (VmWare Workstation, Oracle VirtualBox или может какой-то другой по вкусу). Мы используем VmWare. После этого создаем виртуальную машину и разворачиваем в ней тот образ Linux, на котором будут работать наши проекты в production. Устанавливаем Web-сервер, СУБД, в общем все, что нам нужно для запуска проекта. Кстати, если есть образ виртуалки для production, то еще лучше — можно его и взять за основу.

Виртуалку удобнее всего подключить через bridged-сетевой интерфейс. Так она будет полноценным участником сети и можно будет легко показывать результаты коллегам или заказчикам, если пробросить порт из внешнего мира.

Сетевая папка

Первый вопрос, который у нас встал на этом этапе. Нам теперь что, скрипты проекта через putty редактировать?! И очевидное решение, которое мы нашли, было удивительно простым. В Windows-машине нужно завести отдельную папку, в которой будут лежать все наши проекты. Эту папку нужно расшарить для доступа по сети и примонтировать в корневую директорию, с которой работает Web-сервер.

Чтобы все это работало надежнее, я написал скриптик cifs_mount.sh, буквально из 2 строчек кода, который поставил в виртуалке на запуск раз в 5 минут.

Скрипт проверяет, не отвалилась ли шара (простите мой французский). И если отвалилась, обратно ее монтирует.

Файл /root/file_server
//192.168.0.2/Projects

Файл /root/.cifscreds
username=developvm
password=secretpass

В целом, это решение работает надежно, как утюг.

Иногда бывает, что при копировании больших файлов, вылетает ошибка cifs. Как правило, это связано с тем, что в Windows не хватает выделенной памяти для шары. Вылеты происходят из-за того, что Win7 настроена по умолчанию на экономию памяти для сетевых подключений, в частности, размер выделяемого для этих целей пула памяти ограничен, и если для обработки файла требуется больше, то Win7 шлет Linux фатальную ошибку интерфейса и CIFS падает.

Также бывает наблюдаются периодические проблемы с неполной загрузкой страниц (не подгружаются CSS или вообще ошибки при попытке Apache прочитать файл). Причем это возникает время от времени без какой-либо системы.
При этом в логе ошибок Apache следующие ошибки:
[Tue Oct 20 10:44:28.417589 2015] [core:crit] [pid 9632] (5)Input/output error: [client 192.168.1.5:60666] AH00529: /var/www/project/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that ‘/var/www/project/’ is executable, referer: http://192.168.1.102/script.php
[Tue Oct 20 10:44:28.418762 2015] [core:error] [pid 9555] (5)Input/output error: [client 192.168.1.5:60670] AH00132: file permissions deny server access: /var/www/project/css/main/layout-main.css, referer: http://192.168.1.102/script.php

Чтобы ликвидировать все эти проблемы разом, нужно подредактировать реестр Win7, а именно:
1. У HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache установить значение 1
2. У HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\size установить значение 3

После этого перезапустить LanmanServer. “net stop srv”/“net start srv”. На виртуалке перемонтировать шару.

Не стоит пугаться этих нюансов! Они накопились у нас почти за 10 лет разработки с использованием этого подхода.

Итак, что мы имеем. Теперь мы можем работать со скриптами в привычном нам редакторе кода в Windows. А результаты смотреть в браузере, заходя на нашу виртуальную машину. Идем дальше.

Подпапки для проектов.

А что если у нас больше 1 проекта. Каждый раз поднимать новую виртуалку!? Нам на помощь приходят виртуальные хосты. Придется опять написать небольшой скриптик flush_vhosts.sh (сугубо для удобства работы).

Вот что он делает:
1. Очищает конфигурацию виртуальных хостов.
2. Очищает /etc/hosts.
3. Дальше он проходится по всем подкаталогам нашей примонтированной папки и создает для каждого каталога новый виртуальный хост Apache. Если в названии каталога находится страшное слово bitrix, то он добавляет в конфиг виртуального хоста несколько специфических настроек для этой замечательной CMS. Добавляет в /etc/hosts новые записи для созданных виртуальных хостов.
4. Перезапускает Apache.

Мы использует в адресах проектов для разработки условный домен первого уровня wde (web developer environment). Можно использовать local или кому что нравится. У нас разрабатываемые проекты доступны по адресам project1.wde, project2.wde и так далее. При этом виртуальные хосты создаются с директивой ServerAlias *.your-folder-name.wde, то есть все поддомены будут также обрабатываться созданным для папки виртуальным хостом.

Таким образом, если нам нужно начать работу над новым проектом, достаточно создать новую папку в общей папке проектов. Выполнить скрипт flush_vhosts.sh. А в Windows прописать адрес для нового проекта в файле C:\Windows\System32\drivers\etc\host.
192.168.1.166 wde
192.168.1.166 site1.wde
192.168.1.166 site2.wde
. и т.д.

Звездочки файл hosts к великому сожалению, не поддерживает. Надо прописывать каждый адрес, с которым будем работать. Вместо 192.168.1.166 нужно указать ip, который вы присвоили виртуальной машине. После этого соответствующий проект будет открываться в браузере по адресам site1.wde или site2.wde и так далее.

Для удобства, если вы пользуетесь, phpMyAdmin, его можно настроить дефолтным хостом. Тогда при обращении по любому адресу, когда Apache не будет находить соответствующую папку проекта, он будет открывать phpMyAdmin. Главное не забыть прописать этот адрес (например, просто wde) в файле hosts в Windows.

Организация загрузочного меню

Чтобы было совсем удобно. И не приходилось новым членам команды объяснять, как обновить конфигурацию виртуальных хостов, настроить сетевую папку и т.д. Я написал еще несколько скриптов для вывода и запуска частых действий через меню. В них нет ничего сверхестественного, прикладываю — может быть кому-то тоже пригодятся.

Собственно скрипт, выводящий меню. Его нужно прописать в файле .bash_profile домашней директории пользователя, под которым мы входим на виртуалку. Для виртуалки, на которой ведется разработка, я считаю можно входить под root, соответственно добавляем в файл /root/.bash_profile строчку ./menu.sh. Теперь сразу после входа в систему будет запускаться наше меню. При необходимости из него всего можно выйти, нажав Ctrl+C.

Система контроля версий

Дальше остается настроить любимую систему контроля версий. Можно пользоваться desktop-приложением для Windows, можно работать через командную строку в putty прямо на нашей виртуальной машине. Кому, как удобнее.

PS. Кстати, одно из величайших открытий для меня было, что можно поставить git или svn непосредственно на production сервере. Когда я в свое время это понял, это ощущение было сравнимо, наверное, с тем чувством, которое испытал Архимед, когда сел в ванную. Ведь больше не надо мучиться с синхронизацией файлов по ftp\sftp, достаточно ввести svn up или git pull origin master!

Источник