Pip install user куда устанавливает

Инструмент pip и альтернативные источники пакетов — Python: Настройка окружения

Ранее в курсе мы установили пакет cowsay. Если не уточнить иное, то pip устанавливает пакеты из основного индекса — PyPI. Оттуда был взят и пакет cowsay.

В большинстве случаев PyPI — это именно тот источник пакетов, который нам нужен. Но бывают случаи, когда пакет находится в альтернативном индексе — например, внутрикорпоративном. Еще бывает так, что пакет вообще не опубликован ни в одном индексе, а просто загружен на GitHub.

Pip умеет работать и с альтернативными индексами и с репозиториями, содержащими исходный код пакетов. В этом уроке мы рассмотрим оба варианта.

Альтернативные индексы пакетов

Если вызывать команду pip install с опцией —index-url , то pip будет искать пакет и все его зависимости в индексе по указанному url-адресу. Давайте попробуем установить пакет из специального тренировочного индекса Test PyPI :

Заметьте, что url-адрес индекса указан в виде что-то-там/simple — именно так по соглашению должны именоваться индексы.

Test PyPI содержит большинство пакетов, которые есть в основном PyPI, но обычно держателям локальных индексов не хочется хранить у себя копии всех версий всех пакетов. Обычно держатели хранят только свои пакеты, а все внешние зависимости получают из другого индекса — обычно это уже общий PyPI.

У pip и для такого случая есть опция: можно в дополнение к —index-url указать —extra-index-url . В такой конфигурации pip ищет каждый пакет в первом индексе, а если не найдет, то обращается к дополнительному индексу. Команда целиком может выглядеть так:

-m pip install --user --index-url https://test.pypi.org/simple --extra-index-url https://pypi.org/simple dogesay 

Установка пакетов из репозиториев на GitHub

Иногда пакет не хочется выкладывать на PyPI. Например, когда все еще сырой пакет нужно проверить и попробовать установить. В подобных случаях пакеты устанавливают прямо из git-репозиториев. Давайте установим с помощью pip наш учебный hexlet-boilerplates/python-package :

Этот пакет установится, только если у вас pip версии 20 и выше. Если вы увидите ошибку при установке пакета, попробуйте обновить сам pip такой командой:

-m pip install --user --upgrade pip 

Здесь вместо имени пакета указывается тот же url-адрес, который вы использовали бы при клонировании репозитория, но дополненный приставкой git+ . Эта приставка подсказывает pip, что по url-адресу расположен Git-репозиторий — не обязательно размещенный на GitHub.

Во время установки пакета pip вызывает git clone , чтобы клонировать репозиторий во временную директорию. Если репозиторий закрытый, то понадобится ввести имя пользователя и пароль для доступа к репозиторию. Это работает и с приватными репозиториями GitHub.

Вообще pip поддерживает не только Git, но и другие системы контроля версий. Управлять установкой пакетов из этих систем можно очень гибко — например, можно указывать ветки, теги или хеши коммитов, по которым расположена желаемая версия пакета. Подробнее можно почитать в документации .

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Установка pip — Python: Настройка окружения

Если вы устанавливали Python на macOS или Windows по нашим рекомендациям, то pip будет установлен вместе с интерпретатором. На Ubuntu его нужно поставить отдельно с помощью команды:

sudo apt update sudo apt install python3-pip 

Запуск pip

Можно запускать pip непосредственно командой pip . Но лучше воспользоваться более длинной командой, которая гарантированно вызовет самую свежую установленную версию pip для нужной версии Python.

Итак, вызываем pip:

-m pip --version pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8) 

При показе своей версии pip также сообщает, куда установлен он сам и на какой версии Python он запущен.

Обратите внимание на структуру команды, которую мы вызывали. Эта команда означает « python3 , запусти модуль -m с именем pip как программу с параметром —version ».

Если вы в дальнейшем увидите в документации к pip команды, вроде pip help , то смело вызывайте python3 -m pip help — результат будет тот же самый.

Установка первого пакета

Попробуем установить первый пакет. Для примера возьмем пакет cowsay , который мы установим сразу в пользовательское окружение.

Причин для установки туда есть несколько:

• Мы не помешаем своими пакетами другим пользователям системы
• Нам не потребуются права администратора
• Мы не поломаем операционную систему случайной установкой более свежего пакета, чем того требует система (особенно это важно в Linux, где многие системные задачи решаются с помощью Python)

Итак, установим cowsay:

Пакет установился и стал доступен интерпретатору. Теперь мы видим, что он делает — печатает корову, которая говорит заданную пользователем фразу.

Флаг —user команды pip install сообщает pip, что мы хотим установить пакет в глобальное окружение текущего пользователя. Если этот флаг не указать, то pip установит пакет в общесистемное окружение. Старайтесь не делать так, чтобы не мешать другим пользователям системы.

Программа pip, точки входа и PATH

Как мы увидели выше, установленный пакет cowsay может быть использован из кода. Но этот пакет имеет еще и точку входа.

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

При этом нужно обращать внимание на путь до директории, в которую pip помещает такие скрипты — например, на Linux это ~/.local/bin . Этот путь нужно добавить в PATH . Проверьте содержимое PATH , и если путь прописан правильно, то скрипт для cowsay должен работать так:

Точка входа — это всегда Python-модуль, пригодный для запуска в роли программы. Такие программы называют еще исполняемыми файлами — позже мы рассмотрим, как такие делать. Создаваемые pip’ом скрипты вызывают python3 -m имя_модуля , поэтому установленный нами cowsay можно запускать точно так же:

Всегда свежий pip

Как вы могли уже догадаться, сам pip — это тоже точка входа одноименного пакета pip, поэтому мы его запускаем командой python3 -m pip .

Еще pip нужно периодически обновлять. Вы можете установить свежий pip в пользовательское окружение с помощью такой команды:

-m pip install --user --upgrade pip 

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Pip настройка директории для установки пакетов

Pip по умолчанию ставит пакеты в AppData\Roaming\Python\Python38\ что несколько не устраивает. Хотелось бы вернуть старое поведение когда все пакеты ставились в папку с python, или же указать произвольную папку для установки по умолчанию. Устанавливать каждый раз через -target неудобно. Есть возможность это поправить?

Отслеживать
задан 23 авг 2020 в 15:04
3,186 2 2 золотых знака 9 9 серебряных знаков 16 16 бронзовых знаков

А где сам питон стоит? Сколько питон не ставил (всегда в c:/python) — всегда туда же и пакеты падают.

23 авг 2020 в 15:43
c:/python там и установлен, и да раньше все было ок.. а в последних версиях что-то поменялось.
26 авг 2020 в 20:46

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

26 авг 2020 в 22:43

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Можно либо создать конфиг файл для pip, где описать дефолтные значения для ключей командной строки, либо установить специальным образом именованые переменные окружения. Оба способа описаны в юзерзгайде pip https://pip.pypa.io/en/stable/user_guide/#config-file

Отслеживать
ответ дан 23 авг 2020 в 18:53
2,261 1 1 золотой знак 8 8 серебряных знаков 11 11 бронзовых знаков

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

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

pip install instld 

Это можно сделать один раз и прямо в систему.

Далее использование сводится к применению контекстного менеджера:

import installed with installed('some_package') as context: import some_module 

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

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

• У вас просто нет другого способа запустить конфликтующие зависимости или разные версии одной библиотеки одновременно.
• Вы пишете бенчмарк или тест какой-то библиотеки и вам интересно попробовать несколько версий. Тогда вы можете перебрать их в цикле, открывая на каждой итерации по новому контексту.
• Вы выбираете из нескольких библиотек одного класса и экспериментируете с ними в командной оболочке. В этом случае постоянно выходить из оболочки и выполнять pip install не очень удобно, плюс потом бы пришлось подчищать за собой «мусор» (удалять те пакеты, которые не прошли отбор).
• Вы решили поделиться скриптом с другом и хотите отправить его одним файлом. В этом случае удобнее спрятать установку зависимостей прямо в этот файл.

Виртуальные окружения в 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