В релизе Conda 4.6.0 добавлена улучшенная поддержка взаимодействия между Conda и PIP. Эта функция все еще экспериментальная и поэтому по умолчанию отключена.
Благодаря этой совместимости Conda может использовать пакеты, установленные с помощью pip для установки зависимостей, полностью удалять установленное с помощью pip программное обеспечение, и заменять его пакетами Conda, при необходимости.
Если вы хотите попробовать эту функцию, вы можете установить следующую настройку в файле ".condarc":
Файл у вас по пути (для Windows):
Users\UserName\.condarc
Внесите в него:
pip_interop_enabled: true
Команда включения опции в терминале Conda:
conda config --set pip_interop_enabled True
Примечание: включение этой опции может замедлить работу Conda.
После включения опции требуется помнить, что при использовании в репозитории PIP вместе с Conda, надо использовать ключ:
"--user" ("-U")
Этот ключ явно указывает, что PIP должен работать с пакетами ограничиваясь только "пользовательским хранилищем пакетов"
пример: ~/.local/lib/pythonX.Y/site-packages
... и не может эту же операцию совершать с области общих, системных пакетов, при совпадении имен.
Чтобы проверить, где находится ваша user-папка, выполните команду:
python -m site --user-base
Странно, но официальная документация Anaconda утверждает, что:
- используйте pip только после conda
- установите как можно больше требований с помощью conda, затем используйте pip
- pip следует запускать с использованием –upgrade-strategy только-при-необходимости (по умолчанию)
- не используйте pip с аргументом –user, избегайте всех установок "users”
Ну что же, тестируем...
VENV создано с помощью Conda командой:
conda create -n test310 python=3.10
Conda видит все, а PIP не видит ничего, кроме своих пакетов.
Команда:
pip install psutil
Conda увидела пакет, поставленный с помощью PIP, и даже определили "канал", откуда пакет был установлен.
Команда:
conda uninstall psutil
conda install psutil
Conda тот же пакет взяла с conda_forge канала (у себя).
После установки команды:
conda list
pip list
PIP увидел пакет, поставленный Conda из своего канала!
Пробуем ставить "torch" командой "conda install torch" - отказ "Не найден на этих каналах", хотя в каналах как раз числится "pytorch"!
Да и * с тобою, золотая рыбка: "pip install torch" - ставит (я в другом venv ставлю).
pip list
conda list
Conda УВИДЕЛА все новые пакеты, поставленные PIP!
conda list --explict
На пакеты, поставленные PIP, Conda не может найти URL, хотя в ней прописан канал "pypi"...
Но нас интересует не это, а то, сможет ли Conda экспортировать все те пакеты, которые имеются в нынешнем VENV, вместе с пакетами, установленными с помощью PIP - нас интересует "воспроизводимость"!
conda env export > test.yml
Как видим, Conda прекрасно справилась со всеми пакетами!
Теперь попробуем создать "окружение" из этого YML, отредактируем файл, изменив имя "окружения" в первой строке на "test1" и запустим:
conda env create -f test.yml
Именно так воспроизводится Cond-ой экспорт и импорт "виртуального окружения" при "винегрете пакетов" из разных каналов.
Conda первыми ставит именно свои пакеты, отдавая список пакетов pip ему самому разбираться "что там, и с чем кушать".
И при этом импортированное VENV работоспособно в питоне без потери всех установленных пакетов! При экспорте c помощью PIP, он не увидит пакеты Conda (и любые другие), и отправит на "экспорт" только свои!
Выводы:
- Conda показывает явное преимущество перед PIP в экспорте/импорте пакетов.
- клонирование venv через Conda с помощью YML-файлов прекрасно воспроизводит ВСЕ виртуальное окружение вместе с пакетами PIP.
- PIP проигрывает Conda с универсальности использования, не видя никакие пакеты, кроме тех, которые есть в репозитории "pypi".
Это все, что нужно помнить, если вы пользуетесь то Conda, то PIP, или этой "гремучей смесью".
Это пока... пока PIP ставит пакеты из "pypi"...
А что будет, если PIP поставит пакет по имени, но с применением
--index-url
???????
Удалим "torch"
Как видим, PIP удалил сам torch, но оставил "фантики", которые были установлены как "нужны для torch", просто наплевав на них. Это — лишний мусор из ненужных пакетов, которые PIP все время оставляет за собой.
Сейчас установим torch-cuda версию торча, которой нет на "pypi":
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
Как видим, Cuda смогла увидеть только ИМЯ пакета из "dist-info", а вот URL пакеты ей недоступен!
Мне интересно, как поведет себя экспорт/импорт пакетов с помощью PIP, и с помощью Cuda, кто из них сможет восстановить "индекс-юрл".
Экспортируем и это, и то:
Вариант Cuda:
Вариант PIP:
Оба менеджера потеряли URL, хотя корректнее говорить "PIP потерял URL" потому, что для Conda - это не её пакет!
Поскольку при импорте такого списка команду на установку pip-пакетjd Conda отдаст самой PIP, то нам все равно, с помощью чего мы будем импортировать этот список. Я сделаю это с помощью Conda.
Изменим первую строку в YML-файле на "test2":
... и проведем импорт:
conda env create -f test.yml
Как и ожидалось, PIP "сел в лужу", поскольку при установке не сохранил значение внешнего репозитория с "pytorch", и стал искать пакет просто "по имени", а на "pypi" - там только "простой torch"!
Обратите внимание на ключ "-U" (--user), с которым Conda запустила PIP !!!
Это и есть "идеология" Conda - не дать никому вмешаться в глобальные пакеты, а разрешить PIP действовать только в пределах папки пользователя.
Но даже тут можно "подправить" YML-файл вот так вот:
Было:
Стало:
Я просто "подправил" строку установки так, как ее "скушает" PIP, поскольку в такой ситуации Conda просто "подсовывает" PIP-у эту строку.
Сейчас просто удалим папку "test2" в "env" (на уровне файлов) и повторим:
Одной строкой все три пакета не хочет...
Перепишем построчно:
Запустим:
Установилось!!!
pip list
conda list
Все встало, но с указанием на "pypi".
Так что и тут можно "залезть в сапогах на стол" и все подправить.
Если PIP сам принимает в строке список их нескольких пакетов при установке:
python -m pip install torch torchvision torchaudio
... то "в нотации Conda" их надо просто пописывать "по одному пакету на команду", и все.
Собственно, это (пока) все, что пока надо знать при установке пакетов PIP в Conda, и при "смеси" таких пакетов.
Теперь вы знаете, на что ориентироваться при одновременном использовании менеджеров PIP и Conda.
Моей личное (!) мнение:
Conda намного превосходит PIP по своим возможностям, но работает намного медленнее, чем PIP, что связано с тем, что она делает намного больше проверок, и. при наличии большого количества каналов, к ней подключенных, много время тратит на запросы списка пакетов с каждого канала.
Но мой выбор, все же - Conda!
Удачи!
NStor
https://t.me/stable_cascade_rus
https://t.me/srigert
