[Kotobank::most] Pack: one step closer to nowadays for python

• pip – ну а куда без него. Пакетный менеджер, который не умеет в update. Если так хочется обновить – будте добры там pip freeze, xargs, pip –upgrade install туда-сюда. requirements.txt прикольная штука, но всё равно кейсов всех не покрывает. В комьюнити постоянно происходят холивары на тему как всем этим зоопарком пользоваться. Достойное занятие вместо того чтобы перенять удачные концепции манифеста и локов у утилит других ЯП. Например хаскеля или раста. Зависимости можно держать как в requirements.txt, так и в setup.py. При этом всякие сишные модули и прочие вещи, выходящие за рамки обычной питоньей либы можно объявить только в setup.py. При этом людям приходится писать там приличное количество кода. Удобно, чо. Собственно, есть позиция, предписывающая держать версии в requirements.txt, получать их pip freeze из окружения с проходящими тестами, например. То есть это lockfile, по сути, который не надо трогать руками. Ну тогда, его должен генерировать пакетный менеджер по манифесту. Сплошные инкосистенции.

  По делу же, pip использовать придётся и хорошо бы закрыть все эти безумные дыры. Наверняка, для поддержки установки проекта пипом придётся генерировать большой setup.py, значит бойлерплейт, дополняющий функциональность аутсайдера пакетных менеджеров надо куда-то положить отдельно что-ли. Мы же тут упростить вещи хотим.

• pbr – насколько знаю, утилита, позволяющая вынести то что передаётся в setup.py кваргами в отдельный файл (setup.ini). Шёл 2к17, а питонисты продолжали использовать INI. pbr использует openstack, вроде его девелоперы его и написали (pbr то-бишь, опенстек впрочем тоже).
• wheels – возможность редистрибуции кроссплатформенных пакетов для cpython. Не знаю, насколько это полезно. Надо потыкать и расписать поболее.

• virtualenv – скриптики на баше для создания иерархии директорий и проноса в них правильных симлинков. Полезно, вкусно, но надоело уже делать каждый раз это всё руками. Неужели кого-то прёт вообще подобное.
• virtualenvwrapper – насколько знаю это набор чуть более удобных утилит поверх virtualenv для того чтобы впроще было делать это всю рутину руками. Опять же, руками. Надо потыкать да обновить вот это всё сверху.
• pyenv – тоже тулза для жонглирования окружениями, но вроде как умеет ставить интерпретаторы сама. Нужно изучить и расписать.

• tox – cross-environment запускатор разных задач, в основном используется для тестирования в окружении различных питонов. Довольно мало знаю про него, надо потыкать получше и расписать.
• pytest – безумный фреймворк для написания тестов на стероидах. Хакабл до самых низов. Определённо следует изучить и сделать интеграцию.
• nosetest – ну какой-то запускатор тестов и фреймворк. Вроде не представляет интереса поскольку есть pytest.
• unittest – Junit-like фреймворк, а значит кругом классы, методы. Громоздко. Безусловный плюс – поставка в стандартной библиотеке. У pytest имеется интеграция с unittest, что удобно для написания иерархии кастомных тесткейсов, если требуется предоставить определённые моки и делать какие-то вещи на старте и стопе каждого кейса, например, поднятие реальной базы. Да, это получаются уже не юнит-тесты, а функциональные, ну и что?
• pylint – крутой и доставучий статический анализатор. Имеет плагин к pytest. Обладает здоровенным конфигом.

• sphinx – безусловно одна из крутейших систем документирования кода. Имеет свою утилиту для генерации начальной документации с интерактивным режимом. Определённо стоит делать интеграцию, так как это де-факто стандарт документации для питоньих проектов. Других я, впрочем, не видел.

Этот зоопарк до создания проекта надо привезти на хост. Этот зоопарк надо обновлять. Утилиты ещё должны быть заменяемыми. Проекты ещё должны мочь собираться и устанавливаться и проч. без оркестрации и СМС, отдельно утилитами.

Стандартная реализация, первый интепретатор Python, разрабатывается PSF и разработчики остальных интерпретаторов вынуждены поддерживать совместимость с ним на уровне синтаксиса. Написан на С, предоставляет С/Python API, через него же реализована часть стандартной библиотеки и биндинги для сишных либ типа curses.

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

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

Компилятор Python в С и С++.

Альтернативная реализация Python на Python (RPython) и тулчейн для создания эффективных интерпретаторов. Поддерживается Mozilla, которая нормально так вливает в него деньги. Старается успевать за новыми релизами CPython и в последнее время ему это удаётся. Имеет JIT-компилятор, который может выдавать значительный прирост относительно CPython в том случае если код работает достаточно долго чтобы JIT успел прогреться. Имеет проблемы с распространёнными библиотеками и фреймворками, типа Tornado и asyncio, а также высокий порог входа. Для того чтобы писать код как минимум не медленнее CPython, нужно хорошо понимать как написана стандартная библиотека PyPy. В угоду совместимости с CPython там встречаются очень неэффективные вещи, про которые надо знать. Ребята из MailRu очень его любят и рассказывают на конференциях про эти подводные камни, респект.

Компилятор Python в С, JVM и CIL, используется при сборке PyPy. Позволяет вычислять типы во время компиляции.

Компилятор Python в байткод для JVM. Позволяет использовать Java-классы из питоньего кода.

Компилятор Python в CLR. Реализован поверх DLR, части .NET Framework.

Ну это не сам интепретатор вроде, а только человеческий REPL к нему. До SLIME впрочем не дотягивает. Но там всякие удобные вещи типа мультилайна, хистори, автодополнения нормального, удобного хелпа вплоть до сорцов. Запускать REPL в проекте тоже задача будущего Pack, поэтому указал его здесь.