Проблемы с зависимостями

DeepPavlov version: 0.17.2

Python version: 3.10.17

Operating system: несущественно для проблемы

Issue:
DeepPavlov использует довольно устаревшую форму контроля зависимостей(обычный requirements.txt), что создает ряд проблем при использовании модуля в проектах с большим количеством зависимостей, так как зависимости DeepPavlov могут конфликтовать с зависимостями других модулей(или с самим модулем), от чего приходится их всех даунгрейдить или отказываться от использования DeepPavlov

Оправдано ли использование == версий? Или есть возможность юзать range_versioning?

Возможное решение проблемы:

Использовать pip-tools для более гибкого dependency resolution
Использовать полноценный package manager(например, poetry)

Примеры разных конфликтов:

Because deeppavlov (0.17.2) depends on uvicorn (0.11.7)
   and no versions of deeppavlov match >0.17.2,<0.18.0, deeppavlov (>=0.17.2,<0.18.0) requires uvicorn (0.11.7).
  So, because project depends on both uvicorn (^0.17.6) and deeppavlov (^0.17.2), version solving failed.

Because deeppavlov (0.17.2) depends on pytelegrambotapi (3.6.7)
   and no versions of deeppavlov match >0.17.2,<0.18.0, deeppavlov (>=0.17.2,<0.18.0) requires pytelegrambotapi (3.6.7).
  So, because project depends on both pyTelegramBotAPI (4.4.0) and deeppavlov (^0.17.2), version solving failed.

Because deeppavlov (0.17.2) depends on fastapi (0.47.1)
   and no versions of deeppavlov match >0.17.2,<0.18.0, deeppavlov (>=0.17.2,<0.18.0) requires fastapi (0.47.1).
  So, because project depends on both fastapi (^0.75.1) and deeppavlov (^0.17.2), version solving failed.

Because pydantic (1.9.0) depends on pydantic (1.9.0)
   and no versions of pydantic match >1.9.0,<2.0.0, pydantic (>=1.9.0,<2.0.0) requires pydantic (1.9.0).
  And because deeppavlov (0.17.2) depends on pydantic (1.3)
   and no versions of deeppavlov match >0.17.2,<0.18.0, pydantic (>=1.9.0,<2.0.0) is incompatible with deeppavlov (>=0.17.2,<0.18.0).
  So, because project depends on both pydantic (^1.9.0) and deeppavlov (^0.17.2), version solving failed.

Because black (22.1.0) depends on click (>=8.0.0)
   and no versions of black match >22.1.0,<22.3.0 || >22.3.0,<23.0.0, black (>=22.1.0,<22.3.0 || >22.3.0,<23.0.0) requires click (>=8.0.0).
  And because black (22.3.0) depends on click (>=8.0.0), black (>=22.1.0,<23.0.0) requires click (>=8.0.0).
  And because deeppavlov (0.17.2) depends on click (7.1.2)
   and no versions of deeppavlov match >0.17.2,<0.18.0, black (>=22.1.0,<23.0.0) is incompatible with deeppavlov (>=0.17.2,<0.18.0).
  So, because project depends on both deeppavlov (^0.17.2) and black (^22.1.0), version solving failed.

@hadrizi

Добрый день.

@hadrizi, спасибо за issue, мы знаем об этой проблеме и решаем её.
В пре-релизе 1.0.0rc0 мы перешли на range versioning для основных зависимостей. Кроме того, библиотека и модели, не использующие tensorflow, стали поддерживать python3.8/3.9.
Установить пре-релиз можно через pip, явно указав ==1.0.0rc0, или из иcходников, переключившись на соответствующий тэг. Будем рады вашему отзыву на пре-релиз.

@IgnatovFedor

Это решает проблему в целом, однако некоторые зависимости выглядят немного странно. Например uvicorn<=0.17.4 позволяет поставить вресию меньше или равную 0.17.4, таким образом можно поставить версию 0.0.1, которая явно сломает модуль DeepPavlov, но нельзя поставить PATCH'и в рамках 0.17, возможно:

стоит ограничить обновления в рамках MINOR или MAJOR версий, то есть uvicorn~=0.17.4, что трансилруется в uvicorn>=0.17.4, ==0.17.*, или uvicorn~=0.17, что трансилруется в uvicorn>=0.17, ==0.*. NB! второй вариант лучше подходит для уже релизнутых модулей, то есть тех, у которых MAJOR версия больше 0, так как в соотвествии с Semantic Versioning эти версии подвержены изменению публичного интерфейса
сымитаровать caret requirements

cc @IgnatovFedor

Navigation Menu

Repository navigation

Проблемы с зависимостями #1553

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Проблемы с зависимостями #1553

Description

Activity

IgnatovFedor commented on Apr 16, 2022

hadrizi commented on Apr 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions