Как удалить все установленные библиотеки python

Информация о пакете отображается справа. В зависимости от пакета отображается такая информация, как описание, зависимости и лицензирование.

По умолчанию версия по умолчанию будет соответствовать текущей версии пакета.

В разделе информации о пакете нажмите кнопку Установить .

Появится диалоговое окно Установка пакета .

Диалоговое окно Установка пакета может содержать список зависимостей, которые требуются пакету. Если пакеты еще не включены в среду, они также будут установлены.

Активируется кнопка Установка .

В зависимости от размера пакета и зависимостей добавление среды может занять несколько минут. Вы можете отслеживать прогресс в разделе Задачи на странице Менеджер пакетов .

1. Если установка завершится неудачей, наведите указатель мыши на задачу в разделе Задачи для получения дополнительной информации.

Пакет и все зависимости будут установлены.

Удаление пакета

Чтобы удалить пакет из среды conda, выполните следующие действия:

1. Щелкните вкладку Проект на ленте.

Появится страница настроек.
Появится страница Менеджер пакетов .

Некоторые пакеты являются обязательными в ArcGIS Pro и не могут быть удалены. Эти пакеты отмечены значком блокировки .

Информация о пакете отображается справа.

В разделе Информация о пакете нажмите кнопку Удалить .

Появится всплывающее окно Предупреждение .
Пакет удален.

Связанные разделы

• Менеджер пакетов
• Клонирование среды
• Активация среды
• Добавление или удаление среды
• Восстановление среды
• Удаление среды
• Обновление среды
• Обновить пакеты

Виртуальные окружения в Python

Python знаменит своей обширной стандартной библиотекой и девизом «батарейки в комплекте» (batteries included). Даже из коробки Python позволяет удобно и быстро решить огромный пласт задач, например, например, работа с файлами, запуск простого веб-сервера, работа с электронной почтой, парсинг XML и JSON, и так далее. Во всяком случае, это намного удобнее, чем писать shell-скрипты ��

Кроме того, у Python имеется огромная экосистема сторонних библиотек, поддерживаемых сообществом энтузиастов. Эти библиотеки реализуют отсутствующую в стандартной поставке функциональность, либо пере-реализуют уже имеющуюся, но удобнее. Если у вас возникла потребность в какой-то функциональности, то почти наверняка кто-то уже написал для этого библиотеку, и нужно просто погуглить.

Установка сторонней библиотеки

Каждый начинающий программист знает, как установить библиотеку. Набираем

$ pip install requests 

и понеслась! Множество библиотек в своих инструкциях по установке именно так и предлагают их устанавливать. Это и правда работает, это и правда так просто, но есть нюансы. В этом месте закопаны очень популярные грабли, по которым прошлось множество начинающих питонистов, в том числе и я.

Как pip устанавливает пакеты

Давайте разберемся, что же происходит, когда юзер набирает в терминал такую команду. В общих чертах происходит следующее.

1. pip обращается в PyPI (Python Package Index) и находит там запрашиваемый пакет.
2. Пакет скачивается. Обычно это просто zip-архив, который содержит код библиотеки, разложенный внутри согласно формату. Современным и рекомендуемым форматом пакетов является wheel (PEP-427), но в дикой природе встречаются и другие форматы.
3. pip устанавливает пакет.
4. Библиотека установлена, ее можно импортировать и использовать.

Давайте подробнее разберем третий шаг. Установка пакета — звучит загадочно и сложно, но на самом деле ничего сложного здесь не происходит. pip просто распаковывает zip-архив в определенное место (это справедливо для формата wheel, для установки пакетов в других форматах могут потребоваться дополнительные действия, но давайте разберем самый распространённый и простой случай). Куда именно происходит установка? Это можно узнать, выполнив следующую команду:

$ python -m site sys.path = [ '/Users/and-semakin', '/Users/and-semakin/.asdf/installs/python/3.8.2/lib/python38.zip', '/Users/and-semakin/.asdf/installs/python/3.8.2/lib/python3.8', '/Users/and-semakin/.asdf/installs/python/3.8.2/lib/python3.8/lib-dynload', '/Users/and-semakin/env/lib/python3.8/site-packages', ] USER_BASE: '/Users/and-semakin/.local' (exists) USER_SITE: '/Users/and-semakin/.local/lib/python3.8/site-packages' (doesn't exist) ENABLE_USER_SITE: False 

В списке sys.path можно увидеть директорию site-packages — именно туда и будет установлена библиотека. Давайте в этом убедимся.

До установки пакета:

$ ls -l /Users/and-semakin/env/lib/python3.8/site-packages total 8 drwxr-xr-x 3 and-semakin awesome 96 Apr 18 17:39 __pycache__ -rw-r--r-- 1 and-semakin awesome 126 Apr 18 17:39 easy_install.py drwxr-xr-x 7 and-semakin awesome 224 Apr 18 17:39 pip drwxr-xr-x 9 and-semakin awesome 288 Apr 18 17:39 pip-19.2.3.dist-info drwxr-xr-x 7 and-semakin awesome 224 Apr 18 17:39 pkg_resources drwxr-xr-x 42 and-semakin awesome 1344 Apr 18 17:39 setuptools drwxr-xr-x 11 and-semakin awesome 352 Apr 18 17:39 setuptools-41.2.0.dist-info 

$ pip install requests 

После установки пакета:

$ ls -l /Users/and-semakin/env/lib/python3.8/site-packages total 8 drwxr-xr-x 3 and-semakin awesome 96 Apr 18 17:39 __pycache__ drwxr-xr-x 7 and-semakin awesome 224 Apr 18 17:41 certifi drwxr-xr-x 8 and-semakin awesome 256 Apr 18 17:41 certifi-2020.4.5.1.dist-info drwxr-xr-x 43 and-semakin awesome 1376 Apr 18 17:41 chardet drwxr-xr-x 10 and-semakin awesome 320 Apr 18 17:41 chardet-3.0.4.dist-info -rw-r--r-- 1 and-semakin awesome 126 Apr 18 17:39 easy_install.py drwxr-xr-x 11 and-semakin awesome 352 Apr 18 17:41 idna drwxr-xr-x 8 and-semakin awesome 256 Apr 18 17:41 idna-2.9.dist-info drwxr-xr-x 7 and-semakin awesome 224 Apr 18 17:39 pip drwxr-xr-x 9 and-semakin awesome 288 Apr 18 17:39 pip-19.2.3.dist-info drwxr-xr-x 7 and-semakin awesome 224 Apr 18 17:39 pkg_resources drwxr-xr-x 21 and-semakin awesome 672 Apr 18 17:41 requests drwxr-xr-x 8 and-semakin awesome 256 Apr 18 17:41 requests-2.23.0.dist-info drwxr-xr-x 42 and-semakin awesome 1344 Apr 18 17:39 setuptools drwxr-xr-x 11 and-semakin awesome 352 Apr 18 17:39 setuptools-41.2.0.dist-info drwxr-xr-x 16 and-semakin awesome 512 Apr 18 17:41 urllib3 drwxr-xr-x 8 and-semakin awesome 256 Apr 18 17:41 urllib3-1.25.9.dist-info 

Как видим, в директорию site-packages добавилась библиотека requests вместе со всеми своими зависимостями.

Важные мысли, которые я пытаюсь донести:

1. установка библиотеки напрямую влияет на файловую систему;
2. у интерпретатора Python есть только одна директория site-packages , куда pip и устанавливает пакеты.

А это значит, что в один интерпретатор Python нельзя установить две версии одной библиотеки одновременно. При установке новой версии предыдущая «перезатирается». Просто как если бы вы распаковали другой архив с совпадающими именами файлов в то же самое место.

Боль — это жизненный опыт

Что же будет, если вам понадобится работать над двумя проектами, которые будут требовать разных, не совместимых между собой версий одной и той же библиотеки? Возможно, между этими версиями в библиотеку были внесены какие-то крупные ломающие изменения, например, переименовались методы/функции или изменился набор аргументов.

Например, проект А:

# requirements.txt requests==2.23.0 

# requirements.txt requests==1.2.3 

Вы просто не сможете работать над такими проектами одновременно. Установка зависимостей одного проекта сломает другой, и наоборот. При переключении между проектами придётся каждый раз устанавливать зависимости нужного проекта, что довольно легко забыть сделать.

Ситуация кажется маловероятной, но я гарантирую, что рано или поздно это случится, если устанавливать зависимости всех своих проектов в один интерпретатор. Всё усугубляется тем фактом, что прямые зависимости вашего проекта тянут за собой свои зависимости (под-зависимости), те, в свою очередь, тоже могут от чего-то зависеть (под-под-зависимости). В итоге вы получаете целое дерево зависимостей. И если где-то в этом дереве окажется библиотека не той версии, что ожидалось, то весь проект может начать очень странно работать. Вы получите такие эзотерические ошибки, которых еще никто в интернете до вас не встречал. Если всё сразу сломалось, то считайте, что легко отделались — по крайней мере, так довольно просто понять, в чём проблема. Но бывают и ситуации намного хуже, когда приложение просто начинает немножко иначе работать, без каких-либо ошибок, и возможно придется потратить долгие часы на траблшутинг, чтобы найти настоящую причину.

Надеюсь, я убедил вас, что устанавливать зависимости нескольких проектов в один интерпретатор — это очень-очень плохо. Но как же тогда правильно?

Виртуальные окружения

Решение очевидно — у каждого проекта должен быть свой интерпретатор Python, со своей собственной изолированной директорией site-packages . Это и есть основная идея, стоящая за виртуальными окружениями. Виртуальное окружение — это самостоятельная копия интерпретатора со своими пакетами.

Как создавать виртуальные окружения

Начиная с Python версии 3.5 (на данный момент это самая старая из официально поддерживаемых версий языка, так что справедливо ожидать, что как минимум везде установлен Python 3.5 или новее), создать виртуальное окружение стало очень просто:

$ python -m venv

Например, допустим, что мы работаем над проектом blog_source :

# заходим в директорию с проектом $ cd src/blog_source # создаем виртуальное окружение прямо рядом с кодом в директории env $ python -m venv env 

Создавать виртуальное окружения рядом с кодом — это распространённая практика, так проще ничего не перепутать, но вообще виртуальное окружение может быть где угодно, и директория тоже может называться как угодно. Обратите внимание, что если вы создаете виртуальное окружение в директории под управлением системы контроля версий (git), то его не нужно коммитить. Лучше вообще добавьте его ( env/ ) в .gitignore .

В директорию env будет скопирован тот самый интерпретатор, при помощи которого виртуальное окружение и создавалось. Т.е. если

$ python -V Python 3.8.2 

то в виртуальном окружении будет та же самая версия:

$ env/bin/python -V Python 3.8.2 

Активируем окружение

Посмотрим, что внутри директории env :

$ ls -l env/ total 8 drwxr-xr-x 13 and-semakin awesome 416 Apr 18 18:55 bin drwxr-xr-x 2 and-semakin awesome 64 Apr 18 18:55 include drwxr-xr-x 3 and-semakin awesome 96 Apr 18 18:55 lib -rw-r--r-- 1 and-semakin awesome 113 Apr 18 18:55 pyvenv.cfg $ ls -l env/bin/ total 88 -rw-r--r-- 1 and-semakin awesome 8471 Apr 18 18:55 Activate.ps1 -rw-r--r-- 1 and-semakin awesome 2218 Apr 18 18:55 activate -rw-r--r-- 1 and-semakin awesome 1270 Apr 18 18:55 activate.csh -rw-r--r-- 1 and-semakin awesome 2422 Apr 18 18:55 activate.fish -rwxr-xr-x 1 and-semakin awesome 268 Apr 18 18:55 easy_install -rwxr-xr-x 1 and-semakin awesome 268 Apr 18 18:55 easy_install-3.8 -rwxr-xr-x 1 and-semakin awesome 250 Apr 18 18:55 pip -rwxr-xr-x 1 and-semakin awesome 250 Apr 18 18:55 pip3 -rwxr-xr-x 1 and-semakin awesome 250 Apr 18 18:55 pip3.8 lrwxr-xr-x 1 and-semakin awesome 59 Apr 18 18:55 python -> /Users/and-semakin/.asdf/installs/python/3.8.2/bin/python lrwxr-xr-x 1 and-semakin awesome 6 Apr 18 18:55 python3 -> python 

Обратите внимание, что в директории bin есть некий файл activate в нескольких вариантах для разных шеллов. Это и есть «точка входа» в виртуальное окружение. Просто создать виртуальное окружение мало, нужно его активировать. Но сначала проверим, какие python и pip (исполняемые файлы) используются в обычном режиме работы:

$ which python /Users/and-semakin/.asdf/shims/python $ which pip /Users/and-semakin/.asdf/shims/pip 

Это мой обычный Python, вне виртуального окружения, назовём его глобальным. Теперь активируем виртуальное окружение:

$ source env/bin/activate (env) $ 

Для Windows процесс активации будет отличаться (допустим, что виртуальное окружение создано в C:\src\blog_source ):

# cmd C:\src\blog_source\> env\Scripts\activate.bat # либо в PowerShell PS C:\src\blog_source\> env\Scripts\Activate.ps1 

Обратите внимание, что приветствие шелла изменилось (добавилось (env) ), чтобы показать, что мы «внутри» виртуального окружения под названием env .

Теперь проверим еще раз, какие python и pip используются:

(env) $ which python /Users/and-semakin/src/blog_source/env/bin/python (env) $ which pip /Users/and-semakin/src/blog_source/env/bin/pip 

Посмотрите на пути — мы внутри виртуального окружения! Теперь можно смело устанавливать любые пакеты, и это никак не повлияет на глобальный Python или на другие виртуальные окружения:

(env) $ pip install requests flask whatever-you-need 

Можно запускать любые файлы, и они будут иметь доступ к установленным пакетам:

(env) $ python make_money.py Done! You are rich! 

IDE тоже нужно настроить, указав путь к bin/python внутри виртуального окружения, тогда редактор сможет лучше вам помогать.

По завершению работы с виртуальным окружением можно просто набрать deactivate , либо закрыть окно терминала:

(env) $ deactivate $ which python /Users/and-semakin/.asdf/shims/python 

И мы видим, что команда python снова вызывает глобальный интерпретатор. При этом виртуальное окружение осталось в своей директории, оно просто не активно. В следующий раз, когда будет нужно поработать с виртуальным окружением, не забудьте снова его активировать.

Виртуальное окружение можно полностью удалить, когда оно перестанет быть нужным:

$ rm -r env/ 

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

Вот так можно работать с виртуальными окружениями в Python. Всегда устанавливайте зависимости проектов только в изолированные виртуальные окружения. Не смешивайте зависимости разных проектов в одном окружении.

Когда в инструкции по установке библиотеки написано pip install . , подразумевается, что у читателя есть понимание, что он делает. Думаю, разработчики библиотек не пишут про создание виртуальных окружений только потому, что это сильно раздуло бы все инструкции.

Ничего не устанавливайте в глобальный интерпретатор

Иногда возникает желание установить какой-нибудь пакет прямо в глобальный интерпретатор, потому что по смыслу этот пакет вроде как должен быть вне виртуальных окружений. Например, это может быть какая-нибудь программа, типа poetry , docker-compose , youtube-dl или howdoi . Руки набирают в терминал:

$ pip install poetry 

Установка начинается, прогресс-бары заполняются, но в итоге всё завершается чем-то типа такого:

error: could not create '/lib/python2.7/site-packages/poetry': Permission denied 

Можно попробовать установить, используя sudo , и это сработает, но это считается очень плохой практикой, и я настоятельно рекомендую так не делать по нескольким причинам:

1. Угроза безопасности. В секции про установку пакетов я упомянул, что для пакетов других форматов, кроме wheel, могут потребоваться дополнительные действия. На самом деле, при установке пакета формата sdist исполняется файл setup.py , в котором потенциально могут содержаться любые действия — от честной установки пакета, до rm -rf / или установки криптомайнера в систему. Т.к. в PyPI пакет загрузить может кто угодно, никогда нельзя быть уверенным, что именно сделает пакет при установке. Выполнять такой скрипт с системными привилегиями ( sudo ) — не самый мудрый ход.
2. Может нарушить целостность системы. Часто в операционных системах принято устанавливать программы через пакетный менеджер (будь то apt , dnf или pacman ). Этот же пакетный менеджер затем может без следа удалить установленную программу, потому что он ведёт учёт файлов — какой программе какие файлы принадлежит. Если начать изменять файлы программ каким-либо образом, помимо пакетного менеджера, то это может нарушить его работу. pip , конечно, установит что нужно, но после этого могут возникнуть проблемы с системным пакетным менеджером.

сказать pip , чтобы он установил пакет не в директорию site-packages , а в домашнюю директорию пользователя при помощи флага —user :

$ pip install --user poetry # без sudo! 

Обязательно нужно убедиться, что директория, куда установится пакет, перечислена в переменной $PATH . Путь к директории можно получить при помощи следующей команды:

$ python -m site --user-base /Users/and-semakin/.local 

$ sudo dnf install python-poetry 

Выводы

• всегда устанавливайте зависимости проектов в отдельные виртуальные окружения;
• если нужно установить пакет «глобально», то используйте либо pip install —user . , либо прибегните к помощи пакетного менеджера операционной системы;
• никогда не используйте sudo pip . — считайте, что это табу.

Да, виртуальные окружения — определенно не самая удобная часть разработки на Python, и уж точно не самая простая тема, к этому просто нужно привыкнуть. Несколько раз повторил, выработал привычку — в целом, ничего сложного. Кроме того, экосистема Python развивается очень быстро, и я надеюсь, что скоро правильная установка пакетов и управление виртуальными окружениями станут намного легче. Уже сейчас можно пользоваться такими инструментами, которые в некоторой мере прячут от пользователя виртуальные окружения:

Стабильных вам зависимостей и кода без багов!

Полезно почитать:

• Документация: https://docs.python.org/3/library/venv.html