Comments 57
pip install --user, либо всё равно придётся учить virtualenv. Если же хочется чего-то странного, то можно и поиграть с sys.path, как предлагает ОП. Зачем нужен ещё один глобальный механизм, непонятно.
Я данный PEP рассматриваю больше с точки зрения поставки зависимостей со своим пакетом «все своё ношу с собой», чем полноценную замену virtual env.
Дело не только в том, что управлять зависимостями в python сильно уж сложнее. А в том, возможно, что есть несколько вариантов и они не так активно насаждаются.
Новичкам сложно порой с наскоку понять, как именно перенести своё приложение на сервер, что делать с версиями интерпретатора, библиотек и так далее. всё это создаёт избыточную сложность. Да, сделать можно всё, но наиболее востребованные сценарии всё же должны быть очевидны и просты, желательно настолько, чтобы не задумываясь можно было сделать правильно.
Еще один путь импорта не особо помогает в ситуациях, когда модуль A зависит от модуля B версии 1, а модуль C от модуля B версии 2, а это мне видится больше проблемой, чем необходимость создания virtualenv.
по сравнению
Мне кажется, вы не очень представляете, что сравниваете. Если virtualenv − костыль, то только по сравнению с системами, стоящими на соответствующем уровне абстракции по отношению к CPython и пользовательскому коду. LXC, например. Это было бы понятно: Docker стартовал только в 2013, а virtualenv − в 2007, когда дешёвого способа создать среду исполнения ещё не было. Вы же сравниваете одну фичу интерпретатора языка со сложным компонентом, управляющим средой, в которой этот интерпретатор запускается.
Вот, навскидку:
- Virtualenv позволяет создать несколько окружений с одной и той же версией python под разные архитектуры.
- В virtualenv Python может быть собран с разными флагами (да, CPython часто собирают под специфичные задачи, в отличие от языка, из которого автор притащил этот PEP). В одном окружении может быть собран Python 3.6 с отладкой, во втором — без, а в третьем — какая-нибудь сборка прямо из HEAD, в четвёртом вообще MinGW.
- Пакеты могут тащить с собой бинарники, которые сейчас попадают в venv/bin. Что предлагают авторы? Правильно, скопировать подход, используемый там — npmx (или что щас вместо него), и использовать pipx. Ух, как всё упростилось-то!
Действительно, очень странный PEP. Вместо того, чтобы решить задачу, они усложняют проблему. Вот что мешает параметризировать команду import и оставить только пользовательский каталог библиотек? Например:
import foo.bar <= 0.5каталог в пользовательском пространстве:
python_lib
├── 3.5
└── 3.7
├── foo.0.4
│ └── bar
└── foo.1.0
└── barВы скажите — Ну это же будет помойка, +100500 версий одного модуля, да и как быть с
$ pip install --upgrade <PACKAGE>?
А не нужно апгрейдить существующий пакет! Только инсталлировать каждый раз новый пакет с новой версией. Но тогда же встанет проблема с версиями пакетов которые не используются в проектах и занимают место? Верно, такая проблема будет. Для этого инструмент pip можно снабдить чистильщиком, который просканирует проекты, найдет команду import, сопоставит с текущим каталогом пакетов в пользовательском пространстве и удалит лишние.
Что в этой схеме не так? Почему, например, такое решение не принято до сих пор, которое решает проблему заодно и с зависимостями от тех или иных версий пакетов/библиотек?
import − это плохое решение, оно смешивает разные уровни. Импорт пакета − это код, а версия пакета − это инфраструктура. Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями».Я не понял Вашего аргумента.
Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями»
А почему бы нет? Если автор пакета решил, что его пакет зависит от какой-то версии другого пакета, например версии 1.x, и не работает, скажем с версией 2.x, то как вы будете менять инфраструктуру не залазия в код?
import должен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.автор кода?
Импорты кто пишет? Автор кода? Значит автор кода.
он может быть девопсом, например, и решать пакетированием чисто задачи доставки кода на стейдж/прод.
Так… и в чём сложности?
Он же может выполнить pip requirements.txt который напишет автор кода или какой-нибудь авто-tools сгенерирует его для пакета. Зачем девопсу лезть в код? Не нужно.
А import должен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.
А это я не совсем понял. Речь о том, чтобы "физически" был запрет выбора иной версии пакета в проекте кроме той, что установил devops? Ну так и не будет у него такой возможности.
Не понял, для чего "супер-pip"'у проходить по проекту, когда об этом может позаботится автор пакета и создать requirements.txt?
Даже если это пупер супер pip, то причем здесь редактирование? Максимум что нужно — это чтение.
Еще раз — параметризация import ИСКЛЮЧИТЕЛЬНО для автора проекта. Никаким девопсам никакого до этого дела не должно быть. Для них автор кода готовит requirements.txt.
npm install
Которая автоматом подтягивает локально все зависимости проекта — сильно упрощают жизнь. Аналоги в python несколько переусложнены. Описание зависимостей и их установка в python не такое уж и приятное дело.
Ну вот видимо в этом и разница по сравнению с venv в котором можно задать свою версию самого питона.
Мне вот, кстати, интересно, как это сделать, чтобы разработчик мог забрать репозиторий, ввести команду — и у него создался venv именно с конкретной фиксированной версией питона. А то как фиксировать версии пакета — понятно, а как фиксировать версии питона — не очень.
Мы с вами точно про один и тот же venv?
… что означает, что задача "разработчик забрал, ввел команду и получил повторяемое окружение" силами одного venv не решаема. Печально, придется оставить самопальный зоопарк из conda и venv.
Для таких штук лучше использовать докер. Но, внутри докера, лично я все равно испольую virtualenv это позволяет лугко упрвалять зависимостями.
Если в системе нет нужного питона, его нужно компилить, что достаточноо хлопотно.
Да меня бы устроило "бросить ошибку, если вызвали с неправильным питоном".
Для таких штук лучше использовать докер.
… докерфайл от которого хранить в репозитории и при каждой операции поднимать контейнер? Оверхед же.
— У меня многие проекты в докере. Виртуалэнв в докере, а исходники подмонтируются. Редактируешь на хосте, а запускаешь в контейнере. Перестраивать нужно редко, только если добавляешь внешние пакеты.
Бросать ошибку если уж критично, должен ИМХО, разработчик.
Тогда почему бы разработчику не проверять и версии пакетов?
У меня многие проекты в докере.
Оверхед же.
А в чем оверхэд?
В необходимости держать дополнительный уровень изоляции. Который влияет на все, включая скорость внесения изменений.
Ну и да, при таком подходе virtualenv, очевидно, нафиг не сдался.
— virtualenv нужен, чтобы на целевой системе держать нужные для проекта версии библиотек и пакетов на уровне проекта.
Скорость внесения изменений во что? У меня не влияет.
В код.
virtualenv нужен, чтобы на целевой системе держать нужные для проекта версии библиотек и пакетов на уровне проекта.
… то есть на целевой системе у вас не докер?
1) На машине разработчика исходники подмонтированы с локального диска. ДОкер испольуется в одном случае как легковесная виртуальная машина. в другом как имидж для целевой системыю.
И как вы гарантируете, что на целевой системе без докера нужная вам версия питона?
Никак, я просто знаю, какая на целевой системе.
Прекрасный подход.
1. Разными версиями пакетов проблема не исчерпывается. Virtualenv умеет предоставлять и разные версии самого питона. А значит, Virtualenv все равно придется знать.
2. Virtualenv на столько неудобен, что аналогичные механизмы реализованы для perl, php, ruby? Терзают смутные сомнения, что подобным образом работают gvm для golang и rustup для rust, но не проверял, наверняка не уверен. Вас ни чего не смущает в этом факте?
3. Придется заново выпустить дофига пакетов, которые были собраны с использованием старого инструментария. Не уверен, что мантейнеры всех из них захотят этим заниматься.
4. Даже на установке Virtualenv сэкономить, скорее всего, не получится. Есть такой инструмент для тестирования, tox, который, по сути, надстраивается над virtualenv и гоняет тесты на разных версиях пакетов.
Да и конце -то концов, ни кто не обвиняет плюсы или раст за черезмерную сложность, хотя последний мне дается с заметным скрипом, почему нужно ломать проверенные годами инструменты в угоду непонятно кому и с сомнительной выгодой в перспективе?
ни кто не обвиняет плюсы или раст за черезмерную сложность
Как никто!? Я обвиняю! Плюсы это ужасный монстр. Причем это не ужас, а ужас-ужас.
Правда повторюсь, плюсы не являются основным языком, на котором я пишу.
Использование локальной директории с пакетами в Python уже сейчас