Comments 8
Например, я видел вакансию в pip, и разработчику, который приведет его в порядок, обещают много денег. Возможно, pip станет более универсальным решением. Но нужно, чтобы кто-то взялся за это всерьез
orsinium, может это именно Вы?
Что касается других языков, мне нравится, как работа с зависимостями реализована в Go
Да, там все сделано было предельно классно. Версионирование по коммитам, вложенный вендроинг и так далее. Классная работа с зависимостями :)
В Go сразу есть все необходимое, чтобы работать с зависимостями. В Python нужно все доустановить снаружи, причем еще нужно понять, что именно. Чаще всего достаточно pip, но сейчас появляются другие варианты.
Но ведь встроенный pip модуль в python установки появился еще до выхода go с вендорингом, разве нет?
Как минимум, когда ты хочешь обновить зависимости, то все зависимости просто обновлять страшно, потому что не факт, что даже если прошли тесты, всё будет работать. Например, часто такая ситуация возникает с Celery, потому что полностью протестировать Celery в тестах просто не получается. Можно что-то замокать, что-то упростить, но то, что воркеры запускаются, проверить не получается.
А тут проблема с python или в сложности тестирования условной очереди задач? По идее, данная ситуация вообще не зависит от языка.
И, тем не менее, в Poetry много странного, много привычных фич не поддерживается.
Например, не поддержится отключение проверки ssl сертификата :( Которое благодаря некоторым пакетам (привет, requests !) довольно необходимо.
А так самый печальный вывод из всей статьи — пора валить с pipenv, очень жаль, мне он нравился.
Но ведь встроенный pip модуль в python установки появился еще до выхода go с вендорингом, разве нет?
Pip не встроен в Python, и никогда не был. Есть в стандартной библиотеке модуль ensurepip, который ставит pip из там же лежащего sdist, и всё. Причём даже этот модуль отсутствует, если Python ставить из Debian репозиториев. Насколько я понимаю, связано это с запретом на вендоризацию зависимостей в Debian пакетах, что и не позволяет sdist вложить вовнутрь Python пакета.
А тут проблема с python или в сложности тестирования условной очереди задач? По идее, данная ситуация вообще не зависит от языка.
Хотелось бы иметь удобный способ запустить тесты для всех зависимостей проекта. То есть тесты, написанные самими авторами пакетов. Это позволит проерить целостность окружения, как всё работает на текущей платформе, как этот пакет дружит с другими пакетами в окружении и прочее. И вот этого механизма нет. Есть только возможность сказать sdist, как запускать тесты, но это не получиться сделать для уже установленных завиисмостей (как минимум, потому что setup.py для них не хранится, а то и вообще его не было никогда, если речь про wheel).
Pip не встроен в Python, и никогда не был. Есть в стандартной библиотеке модуль ensurepip, который ставит pip из там же лежащего sdist, и всё. Причём даже этот модуль отсутствует, если Python ставить из Debian репозиториев. Насколько я понимаю, связано это с запретом на вендоризацию зависимостей в Debian пакетах, что и не позволяет sdist вложить вовнутрь Python пакета.
Ну, офицальная дока pip говорит так: "pip is already installed if you are using Python 2 >=2.7.9 or Python 3 >=3.4 downloaded from python.org", а вендоризация пакетов это вопрос уже другой и боле печальный.
Хотелось бы иметь удобный способ запустить тесты для всех зависимостей проекта.
На самом деле не хотелось бы. Потому что те же тесты в python в таком случае должны быть бережно покрыты всякими skipif, что бы покрывать одновременно и опциональные зависимости, и не падать, если их нет. А еще откровенно непонятно, что делать если тесты в пакете просто плохо написаны.
venv?
В JS есть директория node_modules, и у каждой зависимости ее собственные зависимости сложены внутрь неё.
Но… Это не так. Уже много лет как в NPM есть дедупликация зависимостей. Удивительно как люди выражают своё категоричное мнение, не имея минимальной экспертизы в вопросе.
Ну а семантическое версионирование и лок файл появился в JS (вернее, конечно, в NPM) сильно задолго до того, как в Go об этом начали думать.
Это просто фактическая ошибка, которая вводит людей в заблуждение.
Собственно, и проблем с резолвингом не возникает.
И снова нет. Возникают. Потому что дедупликация. И реализовывается она достаточно нетривиально.
Впрочем, ещё одна цитата из поста ещё сильнее.
В Go такого не было, и появилась вендоризация: просто берутся все зависимости и складываются в одну директорию. Это грязное решение, похожее на node_modules, которое в Go какое-то время реализовывалось с помощью сторонних решений.
Вот чем решения похожи, кроме того что… Есть папка для зависимостей?..
Верю, что у вас есть компетенция в питоне, но, видимо, не стоит использовать сравнения из других областей.
Хаос зависимостей в Python