venv vs conda vs poetry
От: Sharov Россия  
Дата: 24.04.23 19:26
Оценка:
Здравствуйте.

А чего в питоне так наплодили этих реализаций виртуальных окружений, чем они друг от друга
отличаются? Правильно ли я понимаю, что питон как линукс, т.е. там все хранится в файлах и все
локально, соотв. я могу скопировать соотв. папочки с исполняемым python и готово новое виртуальное
окружение. Осталось этот процесс как-то автоматизировать.
Т.е. с помощью какого-нибудь питоновского DSL можно легко создавать изолированную инфраструктуру. Это так?

Заранее благодарю.
Кодом людям нужно помогать!
Re: venv vs conda vs poetry
От: Vermicious Knid  
Дата: 26.04.23 15:05
Оценка: 22 (3)
Здравствуйте, Sharov, Вы писали:

S>Т.е. с помощью какого-нибудь питоновского DSL можно легко создавать изолированную инфраструктуру. Это так?


Poetry — это как раз такой DSL, который помогает создавать виртуальные окружения и устанавливать нужные зависимости.
Внутри он в том числе использует venv для этих целей.

conda немного о другом. Это целая экосистема, там и самобытный менеджер пакетов, и коллекция бинарников пакетов/интерпретаторов под разные ОС.
И даже готовый бандл компиляторов C/C++/Fortran для упрощения процесса сборки пакетов. Виртуальные среды — это так, скорее бонусная фича.

Я лично по старой привычке всегда использовал conda (а точнее miniconda). И для разработки, и чтобы устанавливать python и набор пакетов для деплоя.
Не факт, что сейчас — это наилучшее решение. На pypi нынче довольно много готовых бинарников, частенько pip работает быстрее и лучше.

Если нет каких-то особых потребностей, то наверное имеет смысл освоить Poetry как наиболее модное и "молодежное" решение.
Мне кажется, что Poetry становится неким дефолтом для новых Python проектов.
Re[2]: venv vs conda vs poetry
От: Sharov Россия  
Дата: 26.04.23 16:19
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

S>>Т.е. с помощью какого-нибудь питоновского DSL можно легко создавать изолированную инфраструктуру. Это так?

VK>Poetry — это как раз такой DSL, который помогает создавать виртуальные окружения и устанавливать нужные зависимости.
VK>Внутри он в том числе использует venv для этих целей.

Ясно. А все же, в чем особенность питона, что там можно делать свои виртуальные среды?
Я про такие механизмы в других языках не слышал. Понятно, что с докером можно все изолировать,
но ведь это же до докеровская изоляция, еще более простая, на уровне фс. Одна папка -- одна вирт. среда,
и живи там как угодно, ставь что угодно. Речь про изоляцию, а не про ресурсы ОС и проч.

VK>conda немного о другом. Это целая экосистема, там и самобытный менеджер пакетов, и коллекция бинарников пакетов/интерпретаторов под разные ОС.

VK>И даже готовый бандл компиляторов C/C++/Fortran для упрощения процесса сборки пакетов. Виртуальные среды — это так, скорее бонусная фича.
VK>Я лично по старой привычке всегда использовал conda (а точнее miniconda). И для разработки, и чтобы устанавливать python и набор пакетов для деплоя.
VK>Не факт, что сейчас — это наилучшее решение. На pypi нынче довольно много готовых бинарников, частенько pip работает быстрее и лучше.

Я тоже для ml cond'у использую. Иногда не удобно, непонятно где установлен тот или иной пакет -- через pip или через cond'у.

VK>Если нет каких-то особых потребностей, то наверное имеет смысл освоить Poetry как наиболее модное и "молодежное" решение.

VK>Мне кажется, что Poetry становится неким дефолтом для новых Python проектов.

Понял, обращу внимание на Poetry.
Кодом людям нужно помогать!
Re[3]: venv vs conda vs poetry
От: Vermicious Knid  
Дата: 26.04.23 17:04
Оценка: 18 (2) +1
Здравствуйте, Sharov, Вы писали:

S>Ясно. А все же, в чем особенность питона, что там можно делать свои виртуальные среды?

S>Я про такие механизмы в других языках не слышал. Понятно, что с докером можно все изолировать,

Я думаю, что это не потому, что есть какая-то особенность, а скорее появилось как вынужденная мера.
Например, в популярных дистрибутивах Linux часто есть предустановленный Python, раньше это вообще был Python 2.
И избавиться от него насовсем было нельзя, так как на него внутренние утилиты ОС были замкнуты.

Соответственно, если ты ставишь что-то через pip, то есть шанс основательно сломать систему.
Поэтому эти "виртуальные среды" и стали популярны — как костыль, который решает в том числе и эту проблему.

В других языках тоже есть похожие решения, в Rust и node.js есть такие штуки как "version manager" (rustup и nvm).
Задачи решаются другие, но суть инструментов похожа — можно установить отдельно несколько разных версий языка и менять их на лету.

При этом проблем с конфликтами пакетов, как в Python, там не бывает в принципе, поэтому и в "виртуальных средах" нет особой необходимости.
(В ноде зависимости просто копируются в папку самого проекта, а в расте просто крайне удобный и мощный встроенный менеджер пакетов.)
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.