Я использую pip с virtualenv для упаковки и установки некоторых библиотек Python.
Могу представить, что я делаю довольно распространенный сценарий. Я сопровождаю несколько библиотек, для которых я могу явно указать зависимости. Некоторые из моих библиотек зависят от сторонних библиотек, которые имеют транзитивные зависимости, над которыми я не могу повлиять.
Я пытаюсь добиться, чтобы pip install
одна из моих библиотек загрузила / установила все свои восходящие зависимости. В документации по pip я борюсь с тем, могут ли / как файлы требований делать это самостоятельно или действительно ли они просто дополнение к использованию install_requires
.
Могу ли я использовать install_requires
во всех своих библиотеках для указания зависимостей и диапазонов версий, а затем использовать только файл требований для разрешения конфликта и / или замораживания их для производственной сборки?
Давайте представим, что я живу в воображаемом мире (я знаю, я знаю), и мои восходящие зависимости просты и гарантированно никогда не конфликтуют и не нарушают обратную совместимость. Придется ли мне вообще использовать файл требований pip или просто позволить pip / setuptools / distribute установить все на основе install_requires
?
Здесь много похожих вопросов, но я не смог найти ни одного, более простого, например, когда использовать один или другой или использовать их оба вместе гармонично.
источник
Ответы:
Моя философия заключается в том,
install_requires
чтобы указать минимум того, что вам нужно. Он может включать требования к версии, если вы знаете, что некоторые версии не будут работать; но у него не должно быть требований к версии, в которых вы не уверены (например, вы не уверены, сломает ли будущая версия зависимости вашу библиотеку или нет).С другой стороны, файлы требований должны указывать на то, что, как вы знаете , работает, и могут включать рекомендуемые вами дополнительные зависимости. Например, вы можете использовать SQLAlchemy, но предложить MySQL, поэтому поместите MySQLdb в файл требований).
Итак, вкратце:
install_requires
это держать людей подальше от вещей, которые, как вы знаете, не работают, в то время как файлы требований ведут людей к тому, что, как вы знаете, работает. Одна из причин этого заключается в том, чтоinstall_requires
требования всегда проверяются и не могут быть отключены без фактического изменения метаданных пакета. Таким образом, вам нелегко попробовать новую комбинацию. Файлы требований проверяются только во время установки.источник
setup.py
install_requires=
глубинуrequirements.txt
?-U
потому что это может переопределить зависимости из файла требований? Как вы обновляетесь?вот что я вложил в свой setup.py:
# this grabs the requirements from requirements.txt REQUIREMENTS = [i.strip() for i in open("requirements.txt").readlines()] setup( ..... install_requires=REQUIREMENTS )
источник
--extra-index-url
не потребовалось критическое в требованиях, и это взорвалось мне в лицо. Спасибо @RomainHardouinВ Руководстве пользователя Python Packaging есть страница по этой теме, я настоятельно рекомендую вам ее прочитать:
Резюме:
install_requires
здесь можно перечислить зависимости пакета, которые обязательно должны быть установлены для работы пакета. Он не предназначен для привязки зависимостей к конкретным версиям, но допустимы диапазоны, напримерinstall_requires=['django>=1.8']
.install_requires
наблюдаетсяpip install name-on-pypi
и другими инструментами.requirements.txt
это просто текстовый файл, с которым вы можете работатьpip install -r requirements.txt
. Это означало иметь версии всех зависимостей и subdependencies возлагали, как это:django==1.8.1
. Вы можете создать его, используяpip freeze > requirements.txt
. (Некоторые службы, такие как Heroku, автоматически запускаютсяpip install -r requirements.txt
для вас.)pip install name-on-pypi
Не смотритrequirements.txt
, а только наinstall_requires
.источник
Я всегда использую только
setup.py
и,install_requires
потому что есть только одно место, куда можно смотреть. Это так же эффективно, как и файл требований, и нет необходимости поддерживать дублирование.источник