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

/ cc @uranusjr @jtratner @ncoghlan

Некоторые ссылки на проблемы maya :

• kennethreitz / maya # 138 (RemovePipfile.lock из репозитория)
• kennethreitz / maya # 139 (Пропустить pipenv в tox.ini ...)
• kennethreitz / maya # 145 (исправить pendulum>=1.0 в setup.py: версия была в Pipfile, но отсутствовала в setup.py)
• kennethreitz / maya # 143 (PR, показывающий, как проблема pipenv сломала весь пробег Travis)
• kennethreitz / maya # 144 (использование PR Refactor pipenv в соответствии с полуофициальными лучшими практиками)

Мне это тоже нравится. Возможно, нам стоит добавить это в документацию Pipenv или даже в Руководство пользователя Python Packaging .

Следствием вышеприведенного совета, по-видимому, является «откажитесь от детерминированных / воспроизводимых построений CI», что кажется мне очень большим антипаттерном.

Что вы предлагаете в качестве альтернативы, которая все еще допускает детерминизм?

@ tsiq-oliverc Детерминированные сборки на данный момент имеют место, приложение должно быть построено.

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

• сборки должны быть основаны на Pipfile.lock
• каждый контекст выполнения (комбинация каждого варианта Python и ОС) может иметь разные Pipfile.lock результате абстрактных зависимостей библиотеки, определенных в Pipfile
• Репозиторий должен предоставлять отдельные экземпляры Pipfile.lock определенные в репозитории. Обратите внимание, что автоматическая сборка Pipfile.lock во время сборки CI не добавляет детерминизма.

Это требует больших дополнительных усилий. И вы получите библиотеку, которая будет установлена ​​в другом контексте (например, через неделю при стандартной установке появятся обновленные зависимости или две), и которая ничего не получит от того факта, что вы использовали Pipfile.lock , который на данный момент является устаревшим.

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

Если вы думаете, что есть еще одна альтернатива для получения детерминированных сборок для библиотеки Python - опишите ее.

@vlcinsky - Если потребитель вашей библиотеки использует разные версии зависимостей и т. д., тогда это не в вашей власти. Так что я согласен, что у сопровождающего библиотеки нет реального способа справиться с этим.

Но цель здесь, по-видимому, гораздо меньше. В частности, я бы видел следующие цели для сопровождающего библиотеки (которые примерно эквивалентны):

1. Если вы запустите свой CI дважды, вы гарантированно получите тот же результат (несмотря на проблемы с сетью!).
2. Вы можете локально воссоздать (и, таким образом, отладить) поведение, которое вы наблюдаете на CI, даже если это означает запуск Docker / etc. локально.
3. Вы можете с уверенностью сказать своим потребителям: «Моя библиотека ведет себя должным образом с версиями зависимостей X, Y, Z».

Если что-то из этих трех не выполняется, мне кажется, что это противоречит контролю качества.

Итак, да, я бы сказал, что если вы гарантируете поддержку вариантов Python A, B и C для своего потребителя, и они ведут себя достаточно по-разному, чтобы один файл блокировки (и т. Д.) Не разрезал его, тогда у вас должно быть три файла блокировки (или что бы ни).

Однако я недостаточно использовал Pipenv, чтобы знать, насколько просто это будет на практике.

В настоящее время я рассматриваю возможность добавления Pipfile s в несколько библиотечных проектов для системы CI.

Мне абсолютно необходима блокировка зависимостей (+ хеширование) для соблюдения общекорпоративных правил безопасности, и в настоящее время мне не нужно тестировать разные версии Python, поскольку официально поддерживается только одна. И тот факт, что pipenv упрощает настройку локальной среды разработки, включая virtualenv, является приятным побочным эффектом.

И вы получите библиотеку, которая будет установлена ​​в другом контексте (например, через неделю при стандартной установке появятся обновленные зависимости или две), и которая ничего не получит от того факта, что вы использовали Pipfile.lock , который на данный момент устарело.

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

(Да, я говорю о библиотеке, а не о приложении ...)

@ Moritz90 ваш сценарий предназначен для библиотеки Python в корпоративной среде, и там pipenv может помочь, потому что это гораздо более детерминированная среда.

Мое описание нацелено на общие библиотеки Python, такие как flask , request , maya и т. Д., Где контекст гораздо более изменчивый. Пытаясь исправить пару вещей в maya я расстроился, узнав, что во многих случаях использование pipenv вызывает реальные проблемы (обычно скрывает проблемы, которые обычно обнаруживаются), не обеспечивая при этом много или что-либо добавленное. ценить.

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

Я бы сказал, что это один из случаев, когда мы не хотим, чтобы сборки были абсолютно детерминированными. Если вы не закрепляете свои зависимости с помощью == , вы обязуетесь поддерживать поддержку нескольких версий по умолчанию и должны разработать библиотеку таким образом. Обновление зависимости, нарушающее сборку на CI, на самом деле хорошо, потому что оно обнаруживает ошибку в библиотеке. Полностью детерминированные зависимости (управляемые Pipenv) маскируют это. По-прежнему было бы полезно иметь возможность быть детерминированным, когда вы этого хотите, что, как правило, не самое лучшее.

@uranusjr - Конечно. Я согласен с тем, что если вы хотите «недетерминированных построений», то верхний совет вполне может иметь смысл. Фактически, это почти логическая эквивалентность, и ее можно было бы сформулировать гораздо более лаконично: «Если вам не нужны детерминированные сборки, не используйте инструмент ( pipenv ), цель которого - гарантировать детерминированные сборки» 😄.

Но это, конечно, нежелательная цель в целом.

@ tsiq-oliverc хорошее определение области видимости - оно поддерживает целенаправленное обсуждение. Я бы добавил еще одно требование: детерминизм CI не должен скрывать возможные проблемы в тестируемой библиотеке.

Если мы используем Pipenv.lock , создаем virtualenv на его основе и запускаем CI-тест библиотеки, мы выполнили часть функций, которые должна выполнять библиотека, - установили правильные зависимости. Если библиотека как-то сломана в этом плане - предустановленное окружение скроет эту проблему.

Мне кажется более важным обнаружение проблем в библиотеке, чем детерминированный запуск CI. Если есть способ сделать и то, и другое (например, запустить тест за частным индексом pypi, который также может поддерживать детерминизм), у меня нет проблем, но если есть конфликт, у меня есть свои приоритеты.

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

@vlcinsky Конечно, я просто хотел поделиться своим опытом, чтобы убедиться, что обновленная документация также отражает его. Текущая документация отлично объясняет компромиссы:

Для библиотек определите абстрактные зависимости через install_requires в setup.py. [...]
Для приложений определите зависимости и место их получения в Pipfile и используйте этот файл для обновления набора конкретных зависимостей в Pipfile.lock. [...]
Конечно, Pipfile и pipenv по-прежнему полезны для разработчиков библиотек, поскольку их можно использовать для определения среды разработки или тестирования.
И, конечно же, есть проекты, для которых различие между библиотекой и приложением не так очевидно.

(Выделил ту часть, которая применима в моем случае.)

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

@ Moritz90 Полностью согласен. Я пытался выделить этот фокус, но могу сделать его еще более заметным.

@ Moritz90 Я добавил вступительную записку, отражающую ваш комментарий.

@vlcinsky - В этом есть смысл. Я понимаю, что вам явно не нужны недетерминированные сборки, но я думаю, что это неизбежно эквивалентно тому, что вы действительно хотите (т. Е. Обнаруживать проблемы при обновлении зависимостей вашего восходящего потока).

Подумайте вслух: как лучше всего решить эти две противоречивые цели? Одна из возможностей - иметь двухэтапный процесс CI:

1. Детерминированная фаза. Использует Pipfile.lock в вашем репо, поэтому оно полностью воспроизводимо.
2. Недетерминированная фаза. Запускает pipenv update а затем запускает тесты, чтобы получить последнюю из всех ваших зависимостей (что в основном совпадает с поведением без файла блокировки, я думаю?).

@ tsiq-oliverc Чтобы получить детерминированные сборки, я бы подумал о следующей настройке:

• создать задание кеширования pypi: запускать один раз, создавая некоторую форму кеша индекса pypi (как каталог файлов или что-то подобное)
• задание по тестированию библиотеки: использование кеша pypi, но избегание pipenv

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

построить задание кеширования pypi

$ git clone <repo_url> <project_dir>
$ cd <project_dir>
$ pip install pipenv
$ $ # clean pypi cache and make it ready to cache somehow - not described here
$ pipenv install -e .[test]
$ # if we need extra testing packages in pipenv
$ pipenv install <extra_test_packages>
$ # record current requirements expressed in `Pipfile.lock`
$ pipenv lock
$ # if needed, record the `Pipfile.lock` somewhere

Результатами такой работы являются:

• Pipfile.lock виде записанных зависимостей (может помочь разработчикам легко воспроизвести среду)
• предварительно заполненный локальный кеш pypi

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

есть фазы:

• настроить среду для принудительного использования tox , pip и т. д., используя только наш локальный кеш pypi
• запустить тесты CI (избегайте использования pipenv )

что мы получаем

• библиотека протестирована в детерминированной среде
• библиотека протестирована в т.ч. это возможность установить себя самостоятельно
• Pipfile.lock записывает пакеты pypi, которые использовались для установки библиотеки. Его можно использовать для воспроизведения окружения на сайте разработчика.
• адаптация к обновленным пакетам на (возможно, внешнем) pypi проста (перезапустите задание «build pypi cache job)» и выполняется контролируемым образом (содержимое pypi записывается, включая хэши)

Еще одно преимущество заключается в том, что эта установка не требует от разработчиков поддержки Pipfile или Pipfile.lock . Также выполнение тестов в разных контекстах всегда одно и то же ( Pipfile.lock всегда перестраивается в данном контексте).

Чего еще не хватает (и что можно сделать)

Кеш pypi - это часть, которая требует некоторого исследования. Думаю, простого каталога будет достаточно, и, возможно, pipenv уже готов помочь с этим. Возможно, проблема №1731 - это недостающая часть.

Как пакет, который выполняет разрешение зависимостей, многие из наших собственных тестов полагаются на детерминированные сборки, то есть беря известные данные и ожидая разрешенного графа. Для этого мы используем pytest-pypi .

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

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

Я поддерживаю это предложение. Хорошая идея - всегда иметь явное «заведомо исправное состояние» для воспроизводимых сборок и упростить отладку на случай, если обновление что-то сломает, в дополнение к проверке работоспособности более новых минорных версий / исправлений ошибок.

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

@ Moritz90 @techalchemy @uranusjr @ tsiq-oliverc

Вот мое резюме из предыдущего обсуждения.

Конкретные проблемы и предлагаемые решения

Многие контексты выполнения - кто должен поддерживать файл (ы) Pipfile.lock ?

Каждая поддерживаемая ОС и интерпретатор Python вносят свой вклад в матрицу возможных контекстов выполнения.

Например, Flask поддерживает (по крайней мере, в репозитории видны материалы CI):

• ОС Windows (Python 2.7 и Python 3.6)
• Linux (python 2.7, 3.4, 3.5, 3.6, nightly, pypi)
• OSX (py - не уверен, есть ли еще версии)

Он создает 9 различных контекстов выполнения, которые могут отличаться.

Каждый контекст выполнения может иметь разные Pipfile.lock .

Кто их будет поддерживать?

Варианты:

• Разрешить разработчикам делать это вручную (НИ В КОЕМ СЛУЧАЕ)
• Поддерживайте только одну Pipfile.lock для основной платформы разработки (какую платформу предпочитают игнорировать?)
• Автоматизировать создание через CI (ДА)

Предложение: пусть CI сгенерирует файл с помощью pipenv install -e . . Не включайте его в репо, помогите разработчикам выбрать правильные Pipfile.lock в результате автоматизированных сборок.

Разработчикам нужна предсказуемая среда

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

Предложение:

• для многих пакетов изменения зависимостей pypi настолько редки, что это не настоящая проблема
• чтобы исправить среду самостоятельно, разработчик может сгенерировать Pipfile.lock помощью pipenv install -e . за которым следует pipenv lock .
• для репликации среды из неудачного теста разработчик выбирает Pipfile.lock из неудачного теста.
• задача: показать примеры, как применить Pipfile.lock в tox.ini .

CI должен показать сломанный setup.py

Библиотека setup.py может быть повреждена (отсутствует зависимость в install_requires , отсутствует спецификатор версии и т. Д.), И тест CI не должен скрывать такую ​​проблему (путем предварительной установки самостоятельно пропущенных зависимостей).

Предложение:

• доверяйте pipenv install -e . чтобы получить тот же результат, что и при простой установке (в настоящее время с этим возникают некоторые проблемы).
• запустите простой тест установки (без pipenv ) и, возможно, сравните, что результирующий результат pip freeze является подмножеством того, что установлено pipenv .

Обновленные зависимости pypi могут что-то сломать, CI должен обнаруживать такие погони

Некоторое обновление зависимостей может привести к поломке библиотеки, использующей его. CI должен обнаружить отказ по такой проблеме.

Предложение:

• хотя бы один тест должен выполняться против незакрепленной версии
• если CI всегда генерирует новые Pipfile.lock , это не проблема (поскольку мы все равно работаем в незакрепленном режиме)

Режимы CI для разных типов библиотек

Во всех предложенных режимах я старался избегать хранения файлов pipenv в репозитории, избавляя разработчиков от необходимости поддерживать этот действительно сложный материал (автоматизация !!!).

В отличие от моего исходного текста, 2-й и 3-й режимы действительно используют pipenv в сценариях CI.

Режим: Беги, Форрест, Беги!

Простой пакет с меньшим количеством зависимостей, которые не часто меняются.

Просто запустите, как и раньше, в эру pipenv и не усложняйте задачу.

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

Режим: создание и печать

Каждый раз, когда запускается тест CI, генерируйте новый Pipfile.lock который полностью описывает среду, используемую в данный момент.

Pipfile.lock станет артефактом CI.

Если что-то пойдет не так, разработчик может выбрать Pipfile.lock из сломанной сборки, применить его локально и провести тестирование и исправление.

Если кто-то хочет развернуть, можно использовать Pipfile.lock из последней успешной сборки.

Режим: Ледниковый период

Когда изменение зависимостей является реальной проблемой, CI должен один раз создать Pipfile.lock и использовать его в течение определенного периода (месяц?).

Это усложняет настройку CI, поскольку должно быть как минимум два разных задания (одно генерирует Pipfile.lock , другое применяет его и использует в тестах).

Предупреждение: Pipfile.lock должны быть обновлены в данный момент, setup.py изменяет зависимости.

Обратите внимание, что для «Ледникового периода» требуется проверка типа «белка», которая игнорирует замороженный статус и проверяет незакрепленные версии.

Заключительное слово

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

Мое предложение было бы:

• начать просто («Беги, Форрест, Беги»). Вы получаете эффективность и скорость.
• если что-то становится слишком сложным из-за изменения зависимостей, переходите к «Сгенерировать и запечатать». Вы получаете повторяемость в местной среде.
• если дела обстоят совсем плохо, перейдите в режим «Ледниковый период». Вы получаете (временный) детерминизм.

Всякая прибыль чего-то стоит.

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

@vlcinsky Под заголовком «Режим: создать и запечатать» имеет смысл упомянуть, что последний успешный Pipfile.lock всегда должен храниться, например, объявив его как артефакт Дженкинса. С этим изменением было бы хорошо рекомендовать эту настройку для большинства проектов. Как и @ tsiq-oliverc, я бы никогда не рекомендовал первый режим.

Чем больше я думаю об этом, тем больше чувствую, что эта документация станет разделом о том, почему использование pipenv для сборок CI - отличная идея, даже если вы разрабатываете библиотеку.

@ tsiq-oliverc Подавляющее большинство обычных пакетов python находятся в режиме «Выполнить, Форрест, Выполнить». Я помог некоторым из этих пакетов ввести tox и pytest , потому что я чувствовал, что это будет способствовать заданному качеству пакета и потому, что у меня было довольно четкое представление о том, как это можно сделать хорошо.

Теперь есть еще один отличный инструмент, и мне интересно, как правильно использовать pipenv в общих проектах Python, чтобы способствовать его качеству. Я хочу найти один или два хорошо работающих рецепта, которые оправданы и которым легко следовать.

Что бы я сказал проекту Flask?

1. Следуйте лучшим практикам (воспроизводимые сборки) по умолчанию, пока у вас не останется выбора?
2. Добавить 9 файлов Pipfile.lock и настроить политику их обновления?
3. Рефакторинг CI-скриптов для Travis и Appveyor, чтобы они работали в два этапа после режима Ice Age?
4. Измените сценарии CI для Travis и Appveyor, чтобы генерировать артефакт Pipfile.lock для случаев, когда кому-то нужно воспроизвести неудачный тест на своем собственном компьютере?
5. без комментариев, кроме «Большое спасибо за Flask».

Цель - найти функциональный стиль работы. Если он заканчивается на doc - хорошо, если нет - без проблем.

@vlcinsky Я бы сказал, что (1) и (4) должны быть рекомендациями для таких проектов. Хотя без уже существующего Pipfile.lock вы не будете знать версии, используемые в сборке заранее (что нормально за пределами корпоративных сред), вы все равно получите воспроизводимый результат, если сгенерируете и заархивируете файл блокировки. во время сборки.

Изменить : версия tl; dr моей рекомендации будет:

• Всегда проверяйте воспроизводимость ваших сборок, независимо от того, разрабатываете ли вы библиотеку или приложение. pipenv может помочь вам в достижении этой цели.
• Если вы разрабатываете приложение, зафиксируйте Pipfile.lock в своем репозитории и используйте его для развертывания. (Это уже описано в существующей документации.)
• Если вы разрабатываете библиотеку с открытым исходным кодом, сгенерируйте Pipfile.lock на лету в своей CI-сборке и заархивируйте ее для дальнейшего использования.
• Если вы разрабатываете библиотеку и работаете в корпоративной среде с ограничениями, поддерживайте соответствующее количество файлов блокировки и используйте их в своих сборках CI.

(Конечно, в самой документации должно быть немного больше деталей и примеров.)

@ Moritz90 Я изменил «Создать и запечатать», как вы предложили.

Re (1): легко сказать, невозможно выполнить, не вдаваясь в подробности.

По поводу (4): да, я тоже считаю, что «Создать и запечатать» - наиболее приемлемый режим. Но в случае с Flask я не решусь (по крайней мере, на данный момент).

Повторно существующий Pipfile.lock в корпоративной среде: его нужно каким-то образом создать (полу) вручную или автоматически. Я предполагаю, что в корпоративной среде вы не устанавливаете напрямую из общедоступного pypi, а используете какой-то частный, который предоставляет только одобренные пакеты ( devpi-server предоставляет отличные услуги в этом - несколько индексов, контролируемая волатильность опубликованных пакетов, утверждения для внешних пакеты и т. д.). Если процесс сборки Pipfile.lock выполняется в такой среде, он может использовать только то, что одобрено, поэтому, если новая версия должна появиться там, кто-то должен встать и утвердить ее. После сборки CI будет проверено, что она ничего не ломает. А с помощью pipenv check проверка проблем безопасности также может быть автоматизирована.

Думаю, такой рабочий процесс был бы более безопасным по сравнению с тем, чтобы кто-то создавал его (полу) вручную. Но мои знания о корпоративной среде очень ограничены.

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

У меня есть следующее дополнение, которое я хотел бы обсудить:

Для нашего внутреннего пакета python, полностью повторно используемого, опубликованного на нашем внутреннем pypi и т. Д., И даже для моих собственных пакетов python (например, cfgtree , txrwlock , pipenv-to-requirements ) я использую пакет, который некоторые могут уже знать или даже использовать , который абстрагирует эти детали и упрощает жизнь разработчикам Python: PBR.
PBR обычно считывает requirements.txt найденный в корневой папке пакета распространения, и внедряет его в install_requires из setup.py . Разработчику просто нужно поддерживать requirements.txt со свободными объявлениями зависимостей. Пока поддержка Pipfile будет официально интегрирована в PBR, я должен использовать pipenv-to-requirements, который автоматически генерирует requirements.txt из Pipfile чтобы они оба синхронизировались и оба фиксировались. в исходном коде, и PBR правильно выполняет инъекцию после сборки дистрибутива. Я думаю, что можно было бы использовать pipenv для создания этого requirements.txt

Я работаю над поддержкой Pipfile для PBR, чтобы он мог читать Pipfile (а не файл блокировки) и вставлять его в install_requires как в случае с requirements.txt .

Я не знаю, существуют ли другие подобные пакеты, потому что он также делает другие вещи, которые могут не понадобиться людям (версия из истории git, автоматическая генерация AUTHORS и ChangLog).

Но, в конце концов, я действительно чувствую, что писать, поддерживать и управлять версиями библиотеки Python настолько проще, что мне было бы грустно не поделиться этим опытом. Я продвигаю его как «рекомендуемый» способ написания современных библиотек Python в моей компании.

Я действительно считаю, что это похоже на "читерство" на всех трудностях, связанных с библиотекой и pipenv, но в конце концов работа сделана, и разработчики до сих пор счастливы ею пользоваться. Часть обучения python, которую я даю новому разработчику python в своей компании, включает в себя сначала написание библиотеки python, поддерживающей install_requires вручную, а затем переключение на PBR чтобы увидеть, как это станет проще ( и, честно говоря, я поклонник функции семантической фиксации pbr для автоматического создания правильного тега версии semver).

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

Я не обязательно хочу продвигать этот метод как «стандартный» способ создания пакета python, на самом деле это способ «OpenStack», но я хотел бы поделиться своим опытом, и если у других будет аналогичный или противоречивый опыт, я буду рад их услышать и обновить мою точку зрения.

Команда, что вы думаете о своего рода разделе "сообщества" в документации? Чтобы такие пользователи, как я, могли поделиться своим опытом использования pipenv, не обязательно полностью поддерживая команду pipenv?

PS: Я могу переместить это в отдельную проблему, если вы не хотите загрязнять эту ветку.

@vlcinsky (1) очень легко выполнить - поместите свой файл блокировки в свое репо.

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

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

@gsemet знаешь что? Все мои пакеты Python, созданные за последние два года, основаны на pbr - это действительно здорово. И я слежу за вашими попытками поддержать Pipfile в pbr всякий раз, когда могу (несколько одобрений, голоса и т. Д.).

В случае этой проблемы (поиск шаблонов pipenv и антипаттернов для общих библиотек Python) я намеренно пропустил pbr по двум причинам:

• это сделало бы концептуальное обсуждение более сложным
• некоторым людям не нравится pbr по другим причинам (вы их упомянули), и это, вероятно, отвлечет обсуждение

С другой стороны, очень жду вашего рецепта для любителей pbr. Я прочитаю это.

@ tsiq-oliverc вы попали в точку: поместите свой файл блокировки в репо

Это именно та проблема, которая побудила меня начать этот выпуск. Если вы перечитаете начало этой проблемы, вы найдете описание нескольких случаев, когда добавление Pipfile.lock может нарушить ваши тесты CI (либо нарушить запуск сборки, либо скрыть проблемы, которые в противном случае были бы обнаружены, либо установить неправильные зависимости. для данного контекста ...).

Если вы покажете мне репо, где это сделано правильно (общая библиотека Python), я буду счастлив. Или я бы продемонстрировал, какие есть риски или что еще не закончено.

Прохладный ! Я тоже поддерживаю этот резак :)

@vlcinsky Хорошо , давайте перечислим конкретные проблемы и найдем для них решения 😄 (я не знаю ни одной высококачественной библиотеки, которая использует Pipenv, но это в основном потому, что я не смотрел.)

Насколько я могу судить, это конкретные симптомы в исходном посте:

• Скрытие сломанных зависимостей setup.py. Звучит как не проблема - pipenv install -e . , верно?
• Скорее всего, зависимости будут недопустимыми для разных версий Python или в другой ОС. Я понимаю, что это может быть проблемой, но не могли бы вы привести конкретный пример того, где это имело значение на практике? (в контексте файла блокировки)
• Разработчики вынуждены обновлять ... когда обновляются другие библиотеки, которые могут быть использованы внутри библиотеки. Их не заставляют это делать. Они делают это, если хотят гарантировать, что их библиотека работает с версией n + 1, а не с версией n их зависимости. Но обратите внимание, что я уже предлагал альтернативу, которая обеспечивает лучшее из обоих миров.
• Конкуренция с Tox. Я действительно ничего не знаю о Tox. Но да, использование двух инструментов одновременно для управления зависимостями звучит как рецепт катастрофы. Я бы сказал, используйте тот, который лучше всего подходит для этой конкретной задачи.
• Pipenv терпит неудачу. Это звучит как еще одна не проблема - вы можете просто закрепить версию Pipenv (это мое текущее решение, точно так же, как я закрепляю свой образ Docker, мою версию Pip и т. Д.)

@ tsiq-oliverc Должен сказать, ваши комментарии вдохновили меня, и я знаю, что они способствовали более высокому уровню воспроизводимости предлагаемого решения.

Следующее связано с вашим предложением поместить файл блокировки ( Pipfile.lock ) в репо для обеспечения повторяемости:

re Скрытие сломанных зависимостей setup.py. . pipenv install -e . следуют тому, что я предлагаю, но учтите, что это не использование Pipfile.lock , это метод его (повторного) создания. Если кто-то сохраняет Pipenv.lock и использует его для создания virtualenv перед установкой пакета, проблема присутствует.

re Зависимости могут быть недействительными для разных версий python или в другой ОС . Примеров много: doit установленный для Python 2.7, должен быть более старой версии, так как более новая версия отказалась от поддержки Python 2.x. Для зависимости watchdog требуются библиотеки, зависящие от платформы: inotify в Linux, что-то еще в Windows, что-то еще в OSX. Мой бывший клиент говорил: «Этого никогда не случится», и в 50% случаев это происходило в течение 2 недель. Это не лучшая практика для сценариев CI.

re Разработчики вынуждены обновлять .. Представьте себе библиотеку с открытым исходным кодом с 15 участниками. Так легко забыть о регенерации Pipfile.lock новичком или уставшим разработчиком ядра. Например, в пакете maya меня попросили регенерировать Pipfile.lock поскольку в setup.py была добавлена ​​новая зависимость. Это было необходимо? Правильно ли я обновил? Обновил ли я его для всех поддерживаемых контекстов выполнения? Ответы нет, не уверен, нет. В любом случае, спасибо за ваше предложение (оно вдохновило меня на решение, описанное рядом с вашим комментарием).

Повторная конкуренция с tox : Tox позволяет создавать несколько виртуальных серверов и автоматизировать выполнение тестов в них. Типичный tox.ini определяет различные виртуальные параметры для python 2.7, 3.4, 3.5, 3.6 и любых других, которые вам нужны, и позволяет установить там пакет и запустить набор тестов. Установлен powertool серьезных тестировщиков. pipenv не подходит для этой цели, но может помешать установке необходимых вещей. В некотором смысле я последовал вашему совету и предложил использовать более совершенный инструмент (tox) вместо pipenv где это возможно.

re Pipenv терпит неудачу. Это действительно прискорбно. У меня был тест CI (на основе tox), который хорошо работал на localhost, но при запуске через Travis он не удался из-за проблемы pipenv . Если я хочу использовать его сейчас, закрепление не поможет, пока не будет выпущено исправление. Но так оно и есть - подожду.

Обратите внимание, что некоторые части моего исходного сообщения должны быть обновлены, как кажется, использование pipenv в сценариях CI имеет свое оправданное место ("запечатывание" конфигурации virtualenv для возможного дальнейшего использования).

@ tsiq-oliverc Хотя мне изначально понравилось ваше предложение о тестировании как «заведомо хороших», так и последних версий, мне все труднее и труднее оправдывать усилия, чем больше я думаю об этом. Я думаю, вам следует решить сделать либо одно, либо другое, а не то и другое одновременно.

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

@vlcinsky Хотя я согласен с вашим общим мнением о различиях между средами, аргумент «один файл блокировки для каждой конфигурации» звучит для меня как соломинка. На практике вы сможете обмениваться файлами блокировки по крайней мере между некоторыми средами.

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

@ Moritz90

Встреча с соломенником

Что касается слишком большого количества вариантов Pipfile.lock выступающих в роли соломенного человека (чтобы не допустить других к моему полю):

Колба

Я взял проект flask (считая его очень зрелым) и запустил tox-тесты:

Здесь вы видите список протестированных вариантов (только локально в Linux, умножьте его на 3, поскольку Windows и OSX будут выполнять один и тот же набор тестов, но могут привести к разным средам).

На одной ОС выполняется 16 различных тестовых прогонов, 5 из них завершились неудачно, так как они у меня не установлены (это нормально), один связан со сборкой документации (для этого требуется невозможная библиотека), а другой - с покрытием (что также требует импортируемой библиотеки. ):

  coverage-report: commands succeeded
  docs-html: commands succeeded
  py27-devel: commands succeeded
  py27-lowest: commands succeeded
  py27-simplejson: commands succeeded
  py27: commands succeeded
  py35: commands succeeded
  py36-devel: commands succeeded
  py36-lowest: commands succeeded
  py36-simplejson: commands succeeded
  py36: commands succeeded
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy-devel: InterpreterNotFound: pypy
ERROR:   pypy-lowest: InterpreterNotFound: pypy
ERROR:   pypy-simplejson: InterpreterNotFound: pypy
ERROR:   pypy: InterpreterNotFound: pypy

Для каждого из созданных виртуальных файлов я создал requirements.txt файл pip freeze > {venv_name}.txt

Затем рассчитываются хеши для файлов, отсортированные по хеш-значениям, так что все они будут сгруппированы. А вот и соломинка:

b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py35.txt
b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py36.txt
cdf69aa2a87ffd0291ea65265a7714cc8c417805d613701af7b22c8ff2b5c0e4  py27-devel.txt
dfe27df6451f10a825f4a82dfe5bd58bd91c7e515240e1b102ffe46b4c358cdf  py36-simplejson.txt
e48cd24ea944fc9d8472d989ef0094bf42eb55cc28d7b59ee00ddcbee66ea69f  py36-lowest.txt
f8c745d16a20390873d146ccb50cf5689deb01aad6d157b77be203b407e6195d  py36-devel.txt
053e107ac856bc8845a1c8095aff6737dfb5d7718b081432f7a67f2125dc87ef  docs-html.txt
45b90aa0885182b883b16cb61091f754b2d889036c94eae0f49953aa6435ece5  py27-simplejson.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
564580dad87c793c207a7cc6692554133e21a65fd4dd6fc964e5f819f9ab249c  py27.txt
8b8ff4633af0897652630903ba7155feee543a823e09ced63a14959b653a7340  py27-lowest.txt

Страшно, правда? Из всех тестов только два имеют одинаковые замороженные зависимости.

Это реальность общей библиотеки Python с хорошим набором тестов. Теперь вы, вероятно, признаете, что это нечто совершенно отличное от библиотеки python, протестированной в корпоративной среде.

Jinja2

Проверка jinja2 , которая кажется намного проще зверюги:

  coverage-report: commands succeeded
  py26: commands succeeded
  py27: commands succeeded
  py33: commands succeeded
  py35: commands succeeded
  py36: commands succeeded
ERROR:   docs-html: commands failed
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy: InterpreterNotFound: pypy

Глядя на контрольные суммы, я удивляюсь, что py27.txt и py26.txt отличаются:

047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py26.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py33.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py35.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py36.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
743ad9e4b59d19e97284e9a5be7839e39e5c46f0b9653c39ef8ca89c7b0bc417  py27.txt

@vlcinsky Это действительно страшно. Мне интересно, является ли Flask особым случаем или это на самом деле норма, но вы определенно доказали, что я ошибаюсь.

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

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

Общие библиотеки python часто бывают гибкими и настраиваемыми, например, Flask позволяет устанавливать и использовать альтернативные парсеры json, что покрывается отдельным тестовым запуском.

Можно много узнать о тестировании и tox из tox.ini Flask.

самые низкие тестовые варианты проверяют на соответствие самой старой версии зависимостей.

devel тестирует разрабатываемые версии основных зависимостей.

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

tox.ini пирамиды показывает аналогичное количество сред (они также нацелены на 100% покрытие кода).

tox.ini майя очень свежий (2 дня) и простой, даже здесь 4 разных окружения, и py27 отличается по замороженным требованиям от py35 и py36.

@ Moritz90
По поводу клея между пипенв и токс

• pipenv --man показывает некоторые инструкции, как использовать pipenv в командах tox.ini
• tox-pipenv пытается обеспечить дополнительную интеграцию, но на данный момент меня это сбивает.

tox.ini file позволяет запускать произвольные команды, включая pipenv .

pipenv имеет отличную особенность, заключающуюся в том, что при запуске в уже активированном virtualenv (как в случае теста на основе tox) он устанавливается в заданный виртуальный env. Это действительно здорово.

Поскольку нам, вероятно, понадобится сгенерированный Pipfile.lock , необходимо приложить некоторые дополнительные усилия, чтобы получить его и переместить в нужное место (отметьте .tox/py36/Pipfile.lock чтобы предотвратить перезапись с помощью следующего теста. Это возможно, но с некоторым упрощением Может быть, какой-нибудь трюк с переменной окружения для местоположения Pipfile сделает это еще проще.

@vlcinsky

• setup.py - все еще не уверен, что понимаю проблему. Вы запускаете pipenv install -e . один раз, так что теперь setup.py отслеживается через ваш файл блокировки. А затем запускайте pipenv install всякий раз, когда вы добавляете новые пакеты в setup.py.
• Разработчики забывают обновить файл блокировки - pipenv --deploy призван уловить это. Запустите его в своем CI!
• Pipenv терпит неудачу - согласен, если в инструменте есть баги - отстой. Но ошибки обычно исправляются. Это не повод отказываться от философии
• Tox
  
  
  
  • Если Tox хорош для управления тестами, это прекрасно. Если он также отлично подходит для управления пакетами и детерминированными сборками, это даже лучше.
  
  
  • Но если бы это было правдой, у Pipenv не было бы причин для существования. Так что я могу только предположить, что у Tox есть какие-то ограничения.
  
  
  • Как и выше, нынешнее состояние мира (отсутствие хорошего взаимодействия) не похоже на причину для отказа от этой философии.
  
  
• Несколько envs
  
  
  
  • Понятно, что здесь есть хоть какие-то особые случаи, вроде Flask.
  
  
  • У меня нет лучшего предложения о нескольких файлах блокировки (хотя, может быть, в этом отношении у Pipenv есть будущая функция?)
  
  
  • Но даже в этом случае я все еще не уверен, что управление несколькими файлами блокировки является проблемой на практике. В худшем случае кажется, что вы можете создать простой скрипт update-all-lockfiles.sh локально и запустить pipenv --deploy на своем CI, чтобы отловить ошибки.
  
  

@ Moritz90 - Согласен, двухэтапный подход в большинстве случаев может оказаться излишним. В частности, если вы делаете преднамеренные / преднамеренные «ручные» обновления файла блокировки, в этом нет необходимости.

В более общем плане было бы хорошо убедиться, что это «предложение» фокусируется на вещах, которые на самом деле являются серьезными проблемами (на мой взгляд, это (A) обслуживает несколько env, (B) желает уловить изменения в зависимостях восходящего потока). Это не должно быть основано на преходящих вещах (ошибках в Pipenv) или потенциальных недопониманиях того, как инструмент предназначен для использования.

Но даже для этих «сложных» проблем обрамление должно быть таким, как «в некоторых сложных крайних случаях вы можете обнаружить, что базовый рабочий процесс Pipenv недостаточен, поэтому вот некоторые вещи, о которых следует подумать». ИМО, его не следует рассматривать как подход по умолчанию (потому что у большинства людей не будет таких проблем).

Приведенный пример документации @vlcinsky стал бы проще и менее запутанным, если бы Pipenv / Pipfile позволял обрабатывать lib-dependencies , app-dependencies и dev-dependencies . Документы могут выглядеть примерно так:

Используйте параметр lib-dependencies если ваш пакет является общей библиотекой. Пример Pipfile :

[lib-dependencies]
some-lib=="*"
another-lib=="*"
yet-another-one==">=1.0"

[dev-dependencies]
some-dev-tool=="1.1"

Для общих библиотек важно, чтобы диапазоны версий не превышали [lib-dependencies] насколько это возможно, чтобы предотвратить конфликты версий в системе-потребителе.

Если ваш пакет представляет собой приложение (предназначенное для установки pipenv в целевой системе), для которого требуются точные версии зависимостей, вы должны использовать параметр [app-dependencies] . Пример Pipfile :

[app-dependencies]
some-lib=="1.0.12"
another-lib=="1.*"
yet-another-one=="2.0"

[dev-dependencies]
some-dev-tool=="1.1"

/ Конец примера документа

Другой подход может быть Pipfile.lib и Pipfile.app .

Я думаю, что что-то подобное избавило бы от необходимости в блоке разделов анти-паттернов и сторонних инструментах, чтобы заполнить пробел.

Вызов инструмента упаковки pipenv вводит в заблуждение, если кто-то ожидает, что он создаст библиотеки Python или будет активно участвовать в их создании.

Я думаю, что это настоящая проблема, которая приводит к большим недоразумениям. Особенно среди людей, которые привыкли к менеджерам пакетов на других языках программирования (например, JS, Rust, Elm). Мне потребовалось несколько месяцев и время от времени на чтение проблем с GIthub, пока я не понял, что неправильно использую Pipenv и setup.py.

@feluxe

Ваши [lib-dependencies] или Pipfile.lib - это то, что мы имеем сегодня в Pipfile (как абстрактные зависимости - максимально широкие).

Ваши [app-dependencies] или Pipfile.app - это то, что мы имеем в Pipfile.lock (в виде конкретных зависимостей).

pipenv и его файлы могут использоваться в двух разных ситуациях - разработка библиотеки или подготовка развертывания приложения, но, вероятно, не для обоих сразу. По этой причине я не вижу веских причин для добавления дополнительных разделов в Pipenv . Разработчики обязаны знать, какой цели будет служить Pipfile .

Я думаю, что это настоящая проблема, которая приводит к большим недоразумениям. Особенно среди людей, которые привыкли к менеджерам пакетов на других языках программирования (например, JS, Rust, Elm). Мне потребовалось несколько месяцев и время от времени на чтение проблем с GIthub, пока я не понял, что неправильно использую Pipenv и setup.py.

Согласовано. Трехсекционное решение - тоже очень интересное решение, которое я никогда не рассматривал, и оно кажется правильным и (на удивление!) Простым.

Исходя из опыта работы с Python, я всегда чувствовал, что пакет Node package.json делает это неправильно (Rust лучше, потому что у него есть компилятор и компоновщик, и он может решить эту проблему на более позднем этапе). Обработка зависимостей приложений и библиотек таким же образом просто не будет работать для языка сценариев, такого как Python, по крайней мере, в абстрактном смысле - то есть это может работать для вас, но общий инструмент, такой как Pipenv, не может этого сделать, потому что он должен быть общий.

Хотя концепция трехсекционного решения мне нравится, это все же довольно несовместимое изменение существующей экосистемы. Это пространство уже заполнено setup.py, setup.cfg и (потенциально) pyproject.toml. Если Pipenv (а точнее, Pipfile) хочет переместиться в пространство, его необходимо объединить со связанными проектами, такими как pip (в идеале поддержка библиотеки должна поддерживаться непосредственно им) и flit .

Как я уже упоминал в других вопросах, касающихся обработки зависимостей lib / app, это обсуждение необходимо довести до pypa-dev (список рассылки) и / или процесса PEP, чтобы его могли лучше услышать другие стороны и соответствующие лица, прежде чем Pipenv (Pipfile) может двигаться в любых направлениях.

@vlcinsky

Ваши [lib-dependencies] или Pipfile.lib - это то, что у нас есть сегодня в Pipfile (как абстрактные зависимости - максимально широкие).

Извините, если это было непонятно. Мои lib-dependencies предназначены для того, чтобы люди в настоящее время вкладывают в setup.py / install_requires . Может быть, pypi-dependencies было бы лучшим именем для того, что я имел в виду.

@uranusjr

Это пространство уже заполнено setup.py, setup.cfg и (потенциально) pyproject.toml.

Pipenv (инструмент командной строки) может взаимодействовать с setup.py . Просто раздел зависимостей setup.py нужно будет переместить в Pipfile. По крайней мере, в моем воображении :)

Как я уже упоминал в других вопросах, касающихся обработки зависимостей lib / app, это обсуждение необходимо довести до pypa-dev (список рассылки) и / или процесса PEP, чтобы его могли лучше услышать другие стороны и соответствующие лица, прежде чем Pipenv (Pipfile) может двигаться в любых направлениях.

Хорошо, извините за беспокойство;) Если я найду время, я напишу что-нибудь для рассылки.

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

@uranusjr - Я

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

@ tsiq-oliverc Поскольку лучшая практика приложения требует, чтобы вы закрепляли свои зависимости, библиотеки также начнут закреплять свои, если они используют один и тот же источник файлов требований. Это привело бы к проблемам с разрешением зависимостей.

Скажем, у моего приложения две зависимости A и B, обе зависят от C, но A выводит v1, а B выводит v2. Скомпилированные языки позволяют инструментальной цепочке обнаруживать это во время компиляции и решать ее многими способами. Rust, например, делает это во время компоновки - конечный исполняемый файл будет содержать две копии C (v1 и v2), причем A и B связаны с каждой из них. В мире C ++ это можно было бы решить с помощью динамических библиотек; поиск символов выполняется даже позже (во время выполнения), но идея та же - компилятор знает, что вам нужно (из интерфейса, который вы используете), и может действовать соответствующим образом.

Языки сценариев не могут этого сделать, потому что они не знают, что вы действительно хотите сделать, пока не дойдут до вызова. Node работает над этим, всегда предполагая, что зависимости несовместимы (A и B всегда получают свой собственный C, даже если две копии идентичны), но это приводит к новому классу проблем и приводит к неудобным взломам, таким как взаимозависимости, которые все (Надеюсь?) Согласен ужасны. Python, вероятно, не хочет туда идти (во всяком случае, он не может, поскольку это, скорее всего, нарушит все существующие установки Python).

Другой способ обойти это - сделать что-нибудь умное в инструментах упаковки, которые «открепят» версию зависимости. Bundler (из Ruby) как бы делает это, рекомендуя людям не включать файл блокировки в гем, чтобы Bundler мог использовать незакрепленные версии в Gemfile вместо закрепленных версий в Gemfile.lock. Но люди склонны игнорировать советы и делать все, что хотят, поэтому вы все равно получаете прикрепленные версии повсюду.

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

@ tsiq-oliverc Питер Хинтьенс где-то написал концепцию «Комментарии приветствуются в форме запроса на перенос».

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

Я попросил вас привести пример библиотеки python, где pipenv используется правильно (или, по крайней мере, используется), а вы не предоставили его.

Вы комментируете качества tox но признаете, что не знакомы с ними, все же повторяя что-то о лучших практиках в мире разработки пакетов Python.

Вы говорите, что Flask - это, возможно, особый случай. Поэтому я поискал в Github проекты python, используя слово «библиотека», отсортированный по количеству вилок (поскольку это, вероятно, отражает, сколько людей занимаются разработкой с ее помощью), проигнорировал весь «прокрученный список чего-то» и подсчитал количество сред для одного. ОС (обычно Linux):

• панды : tox.ini: 6 окружений
• торнадо : tox.ini: 30 !! envs
• Theano : .trafis.yml: 12 конвертов
• scipy : tox.ini: 4 окружения
• Zipline : .travis.yml: 2 envs
• tflearn : .travis.yml: 2 окружения
• yowsup : tox.ini: 7 envs
• свекла : tox.ini: 4 конверта
• werkzeug : tox.ini: 8 окружений
• paramiko : tox.ini: 6 окружений
• docker-py : tox.ini: 6 окружений
• Подушка : tox.ini: 4 envs

Реальное количество сред для запуска тестов будет в 2 (+ Windows) или 3 (+ OSX) раза больше.

tox используется в 2 проектах из 3 (я не сравниваю его с Travis или Appveyor, поскольку они проводят еще один уровень тестирования).

Количество сред для тестирования довольно велико, Flask определенно не самый дикий.

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

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

Может быть, вы знаете золотое правило из «скомпилированного» мира и чувствуете, что детерминизм (или повторяемость) необходим и для Python. Как видите, на самом деле многие проекты Python неплохо живут без него, так что, возможно, золотое правило здесь не применяется так строго.

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

Для достижения этой цели я перебираю вопросы:

• Могу ли я использовать инструмент?
• Как?
• Почему, какую ценность я получил?
• Это вызвало какие-то проблемы? (лишняя работа, скрытие ошибок ...)

@feluxe

Извините, если это было непонятно. Мои зависимости lib предназначены для того, что люди в настоящее время помещают в setup.py / install_requires. Возможно, pypi-dependencies было бы лучшим названием для того, что я имел в виду.

См. Обсуждение pbr в этом выпуске. Это попытка поддержать зависимости библиотек с помощью Pipfile.

Я думаю, что один Pipfile нельзя использовать для двух целей (lib и app), эти вещи нужно делать отдельно. Если вы чувствуете, что это действительно необходимо, не могли бы вы описать цель проекта, в котором он используется? Обычно я стараюсь разделять проекты разработки и развертывания библиотек, поскольку они используются по-разному во времени.

@vlcinsky Я не совсем уверен, где вы хотите это взять (я не уверен, какой пиар вы просите!), поэтому я пока не буду участвовать в этом разговоре.

Чтобы переформулировать TL; DR моей позиции:

1. Детерминированные сборки очень желательны, обычны в индустрии программного обеспечения и легко достигаются с помощью Pipenv.
2. Определенно есть некоторые крайние случаи, и кто-то должен продвигать в них самые современные технологии (с помощью обходных путей или с помощью более совершенных инструментов).
3. Было бы безответственно со стороны документации Pipenv не рекомендовать (1) просто потому, что (2) влияет на небольшую подмножество случаев.

@uranusjr Понятно . Хотя я не думаю, что здесь есть что-то специфическое для языка, просто разные сообщества выбрали разные эвристики для решения проблемы без общего решения - если у вас есть конфликты версий, у вас есть проблема.

Maven / Java (например) заставляет вас думать об этом во время сборки. Способ NPM означает, что у вас возникнут проблемы во время выполнения, если несовпадающие версии пересекают интерфейс. Разрешение времени выполнения (например, Python, динамические библиотеки) означает, что зависимый может дать сбой / и т. Д. если версия зависимости не соответствует ожидаемой.

@vlcinsky

См. Обсуждение pbr в этом выпуске. Это попытка поддержать зависимости библиотек с помощью Pipfile.

pbr кажется красивым и все такое, но он попадает в категорию, которую я пытался решить с помощью этого:

Я думаю, что что-то подобное избавило бы от необходимости в блоке разделов анти-паттернов и сторонних инструментах, чтобы заполнить пробел.

Я считаю, что в таких инструментах вообще нет необходимости.

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

Когда дело доходит до пакетов pypi, я в конечном итоге использовал Pipenv для обработки зависимостей dev, Pipfile для описания зависимостей dev, setup.py для описания зависимостей lib с помощью install_requires и setuptools в setup.py чтобы опубликовать мой пакет с запущенным pipenv run python setup.py bdist_wheel upload . Это то, что я считаю сложным.

На других современных языках мне нужно изучить один инструмент командной строки (менеджер пакетов) плюс один формат файла зависимостей. Документация находится в одном месте, и ее легче отслеживать, а новичок разобрался со всем этим за пару часов. Речь идет о npm init , npm install foo --dev , npm publish . Pipenv / Pipfile уже может сделать большую часть этого, если бы он мог делать все, таких проблем, как эта, не существовало бы.

Я повторяю свой призыв к созданию своего рода "сообщества" / вики для этого обсуждения. Есть несколько "шаблонов", которые могут быть законными, и некоторые из нас могут захотеть поделиться им "способом создания библиотек Python", некоторые, как я, с pbr, а другие могут иметь очень хороший шаблон. Но страница внутри документа pipenv, не уверен, что это хорошая идея.

PS: чтобы подготовить миграцию на новый pypi, вы должны использовать шпагат, а не загрузку python setup.py. Использование «загрузки» следует рассматривать как антипаттерн.

Может быть, pipenv сможет вырастить «публиковать» команды?

@feluxe Возможно, вы захотите взглянуть на стихи . Я просто натыкаюсь на это и кажется, что это то, что вы ищете.

Он делает то, что делает pipenv , и даже больше, и кажется, что они делают это лучше, особенно в отношении управления зависимостями (по крайней мере, они так притворяются). Он выполняет управление зависимостями, упаковывает и публикует все в одном инструменте poetry .

Интересно, смогут ли pipenv и poetry приложить усилия, чтобы наконец дать Python настоящий менеджер пакетов.

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

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

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

Я согласен с тем, что обсуждение этой ошибки выходит из-под контроля сейчас, когда возникла упаковка и публикация (эта ошибка касается только управления зависимостями!), Но не могли бы вы указать нам правильное место для этого обсуждения? Люди получают это здесь, потому что pipenv рассматривается как столь необходимый шаг в правильном направлении, а не потому, что они хотят возложить дополнительные обязанности на сопровождающих pipenv.

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

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

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

Вернуться к теме: Цитата из сообщения @uranusjr о том, почему зависимости должны быть определены в другом файле для библиотек:

Другой способ обойти это - сделать что-нибудь умное в инструментах упаковки, которые «открепят» версию зависимости. Bundler (из Ruby) как бы делает это, рекомендуя людям не включать файл блокировки в гем, чтобы Bundler мог использовать незакрепленные версии в Gemfile вместо закрепленных версий в Gemfile.lock. Но люди склонны игнорировать советы и делать все, что хотят, поэтому вы все равно получаете прикрепленные версии повсюду.

Я, наверное, был слишком силен, чтобы сказать, что это просто не сработает. Но, по крайней мере, все предыдущие попытки потерпели неудачу

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

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

@vlcinsky

Я думаю, что один Pipfile нельзя использовать для двух целей (lib и app), эти вещи нужно делать отдельно.

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

Обратите внимание, что я уже согласился с тем, что Pipfile.lock не должно быть в системе контроля версий для библиотек, если вы не находитесь в той же ситуации, в которой я.

Изменить : Кроме того, если окажется, что самому pipenv действительно нужно знать о разнице, вы можете просто ввести что-то вроде поля груза crate-type прежде чем начинать вводить app-dependencies и lib-dependencies - звучит слишком сложно.

@ Moritz90 Несколько списков рассылки Python были бы хорошими площадками для проведения этого обсуждения.

pypa-dev является наиболее

python-ideas - это место, где можно обсудить идеи, и он хорошо известен всему сообществу Python. Это также будет хорошей отправной точкой, если вы захотите довести это до уровня PEP (в конце концов, я думаю).

@ tsiq-oliverc

Под PR я имею в виду: покажите пример, подтверждающий жизнеспособность вашей концепции.

Так что возьмите какую-нибудь существующую библиотеку, разветвите ее, примените свою (1) - вы говорите, что с pipenv это будет легко, и покажите мне. Я очень старался, и у меня возникли трудности.

Если ваш (2) означает «кто-то другой должен делать эту работу», вашего PR не будет.

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

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

В центре внимания: pipenv (анти) шаблоны для библиотек и приложений Python

Я немного изменил фокус: он говорит не только о (общих) библиотеках Python, но и о приложениях, поскольку его было довольно дешево включать, и он хорошо демонстрирует различия.

Я намеренно исключил все, что предлагало изменения в существующих инструментах, например pipenv , tox и т. Д.

Что такое pipenv а что нет

• это инструмент развертывания, позволяющий определять и применять конкретные зависимости с помощью Pipfile.lock .
• это инструмент управления virtualenv.
• это НЕ упаковочный инструмент в смысле создания пакета python.

Библиотеки и приложения

Продукт (программное обеспечение Python) либо готов к использованию в другом продукте (например, в библиотеке), либо это окончательное приложение, готовое к запуску.

Лично я считаю, что даже «корпоративные библиотеки» попадают в категорию библиотек (действуют те же правила, только меньше контекстов выполнения).

Типы программных продуктов

• библиотека: для использования в другом продукте (библиотеке или приложении)
• приложение: для развертывания и запуска

Способы установки:

• library: pipenv install <package> таким образом "запускаем пакет (разрешение версий для других библиотек)"
• application: pipenv sync таким образом "применяем конкретные зависимости"

Абстрактные и конкретные зависимости

зависимости программного продукта

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

• конкретные зависимости: должны закреплять версии, в идеале с хешами используемых библиотек

  pipenv артефакты:

• Pipfile : абстрактные зависимости

• Pipfile.lock : конкретные (заблокированные) зависимости "

Контексты выполнения

Типичное количество различных контекстов выполнения

• библиотека:
  
  
  
  • python virtualenvs на одной ОС: от 3 до 9 (торнадо использует 30)
  
  
  • количество ОС: от 1 до 3 (Linux, OSX, Windows)
  
  
  • общее количество: от 3 до 18
  
  
• заявление:
  
  
  
  • python virtualenvs на одной ОС: 1
  
  
  • количество ОС: 1
  
  
  • общее количество: 1 (или очень мало)
  
  

Цели, приоритеты и детерминизм CI

Цель CI

• библиотека:
  
  
  
  • код вкл. его абстрактные зависимости позволяют установку и ожидаемую функцию во всех ожидаемых вариантах контекстов выполнения.
  
  
  • когда (частный / общедоступный) pypi получает обновление библиотеки зависимостей, терпит неудачу, если это влияет на установку функции проверенной библиотеки.
  
  
• заявление:
  
  
  
  • при установке (с использованием конкретных / закрепленных зависимостей) вся ожидаемая функциональность предоставляется в одном предопределенном контексте выполнения
  
  

Конкретные цели CI в отношении функциональности:

• библиотека:
  
  
  
  • абстрактные зависимости, объявленные библиотекой, являются полными и включают все необходимые ограничения (только там, где это необходимо): библиотека устанавливается правильно
  
  
  • все ожидаемые варианты использования работают правильно
  
  
• заявление:
  
  
  
  • конкретные зависимости полны и все закреплены, лучше всего вкл. хеши: приложение устанавливается правильно
  
  
  • все ожидаемые варианты использования работают правильно
  
  

Различные режимы тестирования CI

• Режим: «Беги, Форрест, Беги»
  
  
  
  • Подавляющее большинство библиотек Python в настоящее время тестируются таким образом.
  
  
  • используйте tox или подобное ПО для тестирования
  
  
  • Отсутствие использования pipenv и конкретных зависимостей (может быть хорошо для библиотек)
  
  
• Режим: «Создать и запечатать»
  
  
  
  • Нет Pipfile в репозитории
  
  
  • Pipfile.lock создано pipenv install -e .
  
  
  • Pipfile.lock документирует (запечатывает) среду и позволяет позднее воспроизводить virtualenv для анализа проблем.
  
  

• Режим: «Ледниковый период»

  • двухфазный тест
    
    
    
    • при изменении абстрактных зависимостей (определенных в setup.py install_requires ) или обновлении зависимого пакета на pypi, повторно сгенерировать Pipfile.lock помощью pipenv install -e .
    
    
  • запуск функционального теста: запускать при изменении кода библиотеки. Запускается в virtualenv, созданном pipenv sync Pipfile.lock
    

    Как и кем может быть создано Pipfile.lock

• вручную разработчиком (может работать для приложений)

• автоматически при сборке CI (и, пройдя все тесты, объявить это проверенным артефактом)

Приоритет детерминизма перед гибкостью

• библиотека: гибкость (запускать по возможности)

• приложение: детерминизм (выполняется точно так же в выбранном контексте выполнения)

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

• общедоступный pypi (низкий детерминизм, пакеты обновляются в любое время)

• частный pypi (более высокий детерминизм, обновления пакетов можно контролировать)
• абстрактные требования в библиотеках (не должны использоваться для детерминизма)
• конкретные требования ( Pipfile.lock ): полный детерминизм

Разное

Некоторые варианты использования Pipfile.lock :

• (антипаттерн) определяют абстрактные зависимости библиотеки (потому что он должен быть абстрактным)
• (антипаттерн) настроить virtualenv для тестируемой библиотеки (может скрыть абстрактные зависимости сломанной библиотеки)
• задокументируйте точное virtualenv ("печать"), где был запущен тест (таким образом, разработчик может воссоздать его позже для неработающих тестов и поэкспериментировать с ним)
• настроить virtualenv для тестируемого приложения

• развернуть приложение в производство

  Другие подсказки

• Библиотека pbr позволяет определять зависимости абстрактных библиотек через requirements.txt . Обновление чтения Pipfile уже в пути.

• poetry package пытается что-то похожее на pyenv

  Общие проблемы

• «перетащите файл блокировки в репо», и вы получите детерминированные сборки:

  • Подойдет для приложений.
  • Не будет работать для библиотек, так как существует действительно множество контекстов выполнения, и каждый из них может привести к разным Pipfile.lock . Серьезно: flask показывает на 11 разных виртуальных средах (в одной ОС) 10 разных заблокированных зависимостей. Кто будет их создавать и фиксировать?
  • Обратите внимание, что в режиме CI «Создать и запечатать» вы все равно можете получить Pipfile.lock (но сгенерированный сценарием CI), позволяющий регенерировать virtualenv в другом месте.
• Pipfile.lock в репозитории библиотеки
  
  
  
  • если используется для создания virtualenv, он может скрыть неверное определение зависимостей библиотеки в setup.py .
  
  
• Pipfile в репозитории библиотеки
  
  
  
  • если он повторяет абстрактные зависимости (которые должны быть определены в setup.py ), он может скрыть сломанное объявление зависимостей setup.py .
  
  
  • рекомендуется: сгенерировать Pipfile помощью pipenv install -e . или pipenv install -e .[tests] если вам также нужны тестовые зависимости, и они объявлены как дополнительные "тесты" в setup.py
  
  
• добавление pipenv install <something> в скрипты CI
  
  
  
  • сам по себе он не сильно улучшает детерминизм
  
  
  • см. "Сгенерировать и запечатать" режим CI (тогда вся установка в virtualenv должна проходить через pipenv ).
  
  

Выводы

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

Для приложений ситуация прямо противоположная, и здесь детерминизма действительно легко достичь с помощью такого инструмента, как pipenv .

Что делать дальше?

• У меня не будет времени заниматься этим в течение следующих недель или двух.
• Я могу представить себе создание серии записей в блоге где-нибудь (не уверен, где). Если вы знаете это место (в идеале, позволяя провести некоторое обсуждение), было бы естественным местом, чтобы дать ссылку на контент, обсудить и, наконец, возможно (если он сохранится) где-нибудь в камне :-).
• Я предлагаю @uranusjr взять на себя управление этой проблемой (закрыть ее, решить, что делать дальше, перенаправить людей в другое место или что-то, что кажется практичным)

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

@vlcinsky poetry имеет ничего общего с pyenv . Это очень похоже на pipenv (но с гораздо лучшей реализацией в отношении управления библиотеками и приложениями, IMO), но с частью упаковки и публикации.

У вас есть файл pyproject.toml который определяет ваш проект и его зависимости (абстрактные зависимости), и pyproject.lock который описывает закрепленные зависимости и закреплен для любой версии Python и платформы pyproject.toml файл задан, чтобы иметь только один файл детерминированной блокировки, чтобы избежать проблем, с которыми сталкивается pipenv . Только при установке poetry проверит, какие пакеты установить, сравнивая их с окружением.

И когда он упаковывает вашу библиотеку, он будет использовать абстрактные зависимости (а не закрепленную), поэтому вы сохраните гибкость при распространении вашего пакета (например, через PyPI).

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

Поэзия @zface, не использующая закрепленные зависимости, буквально

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

@techalchemy На самом деле я ничего не продаю, я просто направляю идеи, которые можно было бы использовать в pipenv .

И poetry выполняет зависимости контактов в pyproject.lock , точно так же, как pipenv делает в Pipfile.lock . Таким образом, у вас есть воспроизведение, как в pipenv . Если у вас есть файл блокировки, он будет использоваться и устанавливать закрепленную зависимость, и, если я не ошибаюсь, это также то, что делает pipenv .

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

@vlcinsky Есть еще несколько моментов, которые нужно разобрать, исправить или расширить, но я все еще очень заинтересован в том, чтобы они были включены в форму документации, Pipenv или что-то еще. Вы были бы заинтересованы в отправке запроса на перенос? Я был бы более чем счастлив помочь дополнить статью.

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

поэзия также может потребовать больше внимания и вклада. Это было бы лучше всего для сообщества, включая Pipenv. Имея жизнеспособный выбор, люди могут взвесить свой выбор вместо того, чтобы сначала заглядывать в голову Pipenv и жаловаться, что он не делает того, чего они ожидают. Хорошая конкуренция между библиотеками также может стимулировать технические улучшения в области разрешения зависимостей, что и Pipenv, и поэзия делают (и ни то, ни другое не идеально). Мы можем многому научиться друг у друга.

@uranusjr Да, я думаю, кое-что было прояснено и заслуживает того, чтобы поделиться с более широкой аудиторией. Ваша помощь действительно приветствуется.

А как насчет «парного составления документации»? Думаю, что на данный момент эффективнее всего было бы поработать над ней в небольшом масштабе всего в два человека.

Думает сделать (возможно, с одной или двумя итерациями):

• где именно мы могли опубликовать это
• определить элементы документации (статьи, разделы)
• уточнить объем и цель каждого пункта
• согласовать схему
• выявить открытые проблемы
• проработать их
• напишите документ
• опубликовать (и надеюсь, что он будет принят)

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

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

@vlcinsky Также я доступен как @uranusjr в PySlackers (рабочая область Slack), если вы предпочитаете взаимодействие в реальном времени. У Pipenv есть там канал ( #pipenv ).

@uranusjr Это то, что я имел в виду, pipenv , я думаю, не поможет.

Что меня беспокоит, так это то, что pipenv рекламирует себя как the officially recommended Python packaging tool хотя это далеко не инструмент для упаковки, что вводит пользователей в заблуждение. Это просто диспетчер зависимостей в сочетании с диспетчером virtualenv.

Кроме того, вы говорите, что он был вдохновлен Cargo, npm, yarn, которые являются инструментами упаковки вместе с менеджерами зависимостей, а piping - нет.

И вот недостаток pipenv , он просто мутит воду, поскольку люди все равно будут делать те же ошибки, что и раньше, с requirements.txt vs setup.py . Из-за этого проекты по-прежнему будут плохо упакованы с плохо определенными зависимостями в их setup.py . Вот что сделали правильно такие проекты, как Cargo: они обрабатывают все аспекты разработки проектов / приложений для обеспечения согласованности, в то время как проект типа pipenv - нет.

И когда вы говорите:

что и Pipenv, и поэзия делают (и ни то, ни другое не идеально)

Что ты имеешь в виду? Из того, что я видел, их менеджер зависимостей намного более устойчив, чем тот, который предоставляется pipenv . Единственным недостатком является то, что они используют PyPI JSON API, который иногда не имеет информации о зависимостях из-за плохо опубликованных пакетов.

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

И еще кое-что: каково будущее pipenv, если в конечном итоге pip обработает Pipfile ? Будет ли это просто менеджер virtualenv?

Если диспетчер зависимостей поэзии полагается на json api, это не только иногда неправильно из-за «плохо опубликованных пакетов», но и будет очень ограничено в том, что он действительно может правильно разрешить. Api хранилища json публикует _самые недавние_ зависимости, даже если вы имеете дело со старой версией, и если она вообще имеет эту информацию. Мы также использовали json api, это было здорово, потому что он был быстрым, но команда разработчиков инфраструктуры сказала нам не доверять ему. Кажется немного неискренним называть что-то устойчивым, если для начала он полагается на ненадежный источник.

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

Легко помахать рукой и сказать: «Ну, разве это не делает pipenv виртуальным менеджером, если pip может читать pip-файл?» Нет. Pipenv - диспетчер зависимостей. Он управляет идемпотентными средами и генерирует воспроизводимый файл блокировки. Я понимаю, что это должно показаться вам тривиальным, потому что вы отмахиваетесь от этого и сводите этот инструмент к диспетчеру virtualenv, но это не так. Мы разрешаем файлы блокировки и включаем маркеры для версий Python, которых у вас нет, которые вы не используете, и оставляем их доступными, чтобы вы могли точно развертывать и воспроизводить на разных платформах и версиях Python. Мы используем несколько методов разрешения, включая обработку локальных колес и файлов, репозиториев vcs (мы также разрешаем граф там), удаленных артефактов, пакетов pypi, частных индексов и т. Д.

В конце дня pip _ будет обрабатывать pip-файлы, это план, это был план с момента создания формата. Но это то же самое, что спросить: «А как насчет того, когда pip сможет обрабатывать файлы требований?» Вопрос в принципе идентичный. Пип может установить этот формат. На самом деле это не относится ни к одной из описанных мною функций, кроме того, что мы также устанавливаем файлы (кстати, используя pip).

@techalchemy

Api хранилища json публикует самые последние зависимости, даже если вы имеете дело со старой версией, и если у него вообще есть эта информация

Это просто неправильно, вы можете получить зависимости от конкретной версии, вызвав https://pypi.org/pypi/{project}/{release}/json . Если вы просто вызовете https://pypi.org/pypi/{project}/json убедитесь, что вы получите только последние зависимости, но вы действительно можете получить правильный набор зависимостей.

И часть упаковки / публикации проектов python действительно нуждается в улучшении, потому что в конечном итоге это принесет пользу всем, поскольку позволит надежно использовать JSON API.

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

И poetry тоже. И вы можете сделать так, чтобы он не использовал JSON API, чтобы обеспечить использование того же метода разрешения, что и pipenv (с использованием pip-tools). См. Https://github.com/sdispater/poetry/issues/37#issuecomment -379071989, и он по-прежнему будет более устойчивым, чем pipenv (https://github.com/sdispater/poetry#dependency-resolution )

@zface Я скажу это в последний раз, пожалуйста, потому что это так . Если вы считаете, что это неуместно, сообщите об этом официальным лицам, которые рекомендуют Pipenv . Пожалуйста, не кладите эти вещи на Pipenv dev. Это неподходящее место для жалоб, и вы не можете получить здесь решения по своим жалобам. Вы также можете получить более точные ответы на возникающие у вас технические вопросы. Это средство отслеживания проблем для Pipenv, а не доска обсуждений для инструментов упаковки Python и того, как выполняется упаковка Python.

Pipenv не просто полагается на pip-tools для решения проблемы, пожалуйста, прекратите сокращать наше программное обеспечение до одних строк, которые демонстрируют непонимание. Я очень хорошо знаю, как работает PyPI api, я разговаривал напрямую с командой, которая его реализовала.

Это просто неправильно,

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

он по-прежнему будет более устойчивым, чем pipenv (https://github.com/sdispater/poetry#dependency-resolution)

Pipenv в настоящее время не сглаживает графики зависимостей. Указывать на одну конкретную проблему, когда дерево было сплющено, и заявлять, что весь инструмент, следовательно, лучше и устойчивее, глупо, вы снова и снова доказываете, что вы здесь просто оскорбляете pipenv и продвигаете поэзию. Пожалуйста, не торопитесь, такое поведение не приветствуется.

Я согласен, что обсуждение не по теме, это попытка извлечь выгоду из «хороших практик» вокруг pipenv.

Тем не мение,

[...] по-прежнему будет делать те же ошибки, что и раньше, с требованиями.txt и setup.py. Из-за этого проекты по-прежнему будут плохо упакованы с плохо определенными зависимостями в их setup.py.

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

И pipenv (и, вероятно, стихи) - очень хороший шаг вперед.

Необходимость поддерживать с одной стороны Pipfile для приложения и setup.py для библиотек с другой стороны - это не проблема. Как бы сложно мы ни объясняли с помощью большого количества слов, длинных статей и руководств по передовой практике, это слишком сложно для того, что есть на самом деле. Я полностью согласен с тем, что на данный момент это так, но это не должно помешать нам представить лучший и безопасный способ.
В конце концов, как разработчик, я хочу, чтобы один инструмент, возможно, с двумя разными режимами, помогал мне и делал мою жизнь как можно проще.

Они должны быть способом извлечения только той части, которая выполняет requirements.txt/Pipfile из библиотек, таких как PBR, чтобы предложить своего рода 'easy setup.py', оболочку с поддержкой Pipfile arround install_requires , без все нежелательное поведение, которое приносит pbr, и упакуйте это в специальную оболочку setuptools, которая только это делает.

Таким образом, мы сможем получить лучшее от каждого мира:

• pipenv для поддержки Pipfile (с версией как в библиотеках, так и в приложениях)
• pipenv для поддержки Pipfile.lock (версия поддерживается только для приложений)
• можно было бы использовать этот волшебный пакет-оболочку ( pipfile_setuptools , install_requires_pipfile ?), который будет зависимостью первого уровня, задача которой - только ввести Pipfile в install_requires .

Это еще один проект, который не будет связан с pipenv , но по-прежнему нуждается в общей библиотеке парсера Pipfile . Что вы думаете?

@gsemet Насколько я понимаю, PyPA пытается заполнить это pyproject.toml вместо этого, во главе с flit . Вам нужно сначала поговорить с ними (в pypa-dev или distutils-sig) об этом, прежде чем переходить к использованию Pipfile в качестве исходного формата. Что касается синтаксического анализа Pipfile (и файла блокировки), он обрабатывается в pypa / pipfile (которые поставщики Pipenv предоставляют основную логику синтаксического анализа).

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

Я должен признать, что мне немного грустно видеть зависимости, объявленные в pyproject.toml (который принимает роли как setup.cfg выполняемые PBR), в то время как PyPa также поддерживает Pipfile ....

Спасибо за указатель на flit и pipfile. Еще есть pipenvlib Кеннетрайца, который кажется более легким.

PBR setup.cfg кажется более полным по сравнению с официальной документацией (например: data_files ), и повторное использование файла, уже совместно используемого несколькими инструментами (flake8, pytest, ...), может использовать тот же файл, уменьшая количество файл в корне проекта Python)