requirements.txt - это файл, в котором указывается зависимости .Например, ваша программа будет зависеть от Django (ну, вы, вероятно, не хотите реализовывать Django самостоятельно).
В случае, если вы только пишете пользовательское приложение и не планируете его экспортировать (например, какбиблиотека), для других программистов можно закрепить версию библиотеки, например Django==2.0.1.Тогда вы всегда можете предположить (учитывая, что pip удастся установить правильный пакет), что ваша среда будет иметь правильную версию, и, таким образом, если вы будете следовать правильной документации, никаких проблем не возникнет (хорошо должно ) возникнуть.
Если вы, однако, реализуете библиотеку, например mygreatdjangolibrary, то, вероятно, вы не хотите закреплять версию: это будет означать, что все, кто хочет использовать вашу библиотеку, должны будут установить Django==2.0.1.Представьте, что им нужна функция, доступная только в django-2.1 , и они могут - учитывая строгое соблюдение зависимостей - не делать этого: вашей библиотеке требуется 2.0.1.Это, конечно, не поддается управлению.
Поэтому, как правило, в библиотеке стремятся предоставить как можно больше свободы пользователю библиотеки.Было бы идеально, если бы независимо от версии Django, которую установил пользователь, ваша библиотека могла работать.
К сожалению, это создало бы много проблем для разработчика библиотеки.Представьте, что вы должны принять во внимание, что пользователь может использовать Django-1.1 до django-2.1 .На протяжении многих лет было введено несколько функций, которые библиотека затем не может использовать, поскольку программист должен быть консервативным и учитывать, что возможно, что эти функции не существуют в библиотеке, установленной пользователем.
Это становится еще хуже, так как Django прошел некоторый рефакторинг: некоторые функции были позже удалены, поэтому мы не можем просто программировать на django-1.1 и надеяться, что все получится.
Так что вв этом случае имеет смысл указать диапазон поддерживаемых нами версий.Например, мы можем прочитать документацию django-2.0 и посмотреть примечания к выпуску, чтобы увидеть, изменилось ли что-то важное в django-2.1 , и позволить tox протестировать обе версии длятесты мы пишем.Таким образом, мы можем затем указать диапазон, например Django>=2.0,<2.1.99.
. Это также важно, если вы зависите от нескольких библиотек, каждая из которых является общим требованием.Скажем, например, что вы хотите установить библиотеку liba и библиотеку libb, обе зависят от Django, но оба имеют различный диапазон, например:
liba:
Django>=1.10, <2.1
libb:
Django>=1.9, <1.11
Тогда это означает, чтомы можем установить версию Django только между >=1.10 и <1.11.
. Вышесказанное легко становится более сложным.Поскольку liba и libb, конечно, также имеют версии, например:
liba-0.1:
Django>=1.10, <2.1
liba-0.2:
Django>=1.11, <2.1
liba-0.3:
Django>=1.11, <2.2
libb-0.1:
Django>=1.5, <1.8
libb-0.2:
Django>=1.10, <2.0
Так что, если мы теперь хотим установить любой liba и любой libb, нам нужно найтиверсии liba и libb, которые «позволяют» нам установить Django версию, и это не так тривиально, поскольку, например, если мы выберем libb-0.1, то не существует версии liba, которая бы поддерживала«перекрывающаяся» версия Django.
Насколько мне известно, pip в настоящее время имеет нет алгоритм разрешения зависимостей.Он смотрит на спецификацию и каждый раз стремится выбрать самую последнюю версию, которая удовлетворяет ограничениям, и рекурсивно устанавливает зависимости этих пакетов.
Поэтому пользователь должен убедиться, что (sub)зависимости не конфликтуют: если мы укажем liba libb==0.1, то pip, вероятно, установит Django-2.1, а затем обнаружит, что libb не может работать с этим.
Есть некоторые программы разрешения зависимостей .Но проблема оказывается довольно сложной (это NP-hard , если я правильно помню).Это означает, что для данного дерева зависимостей могут потребоваться годы, чтобы найти правильную конфигурацию.