Pipenv не является внутренней или внешней командой исполняемой программой или пакетным файлом

Обновлено: 08.07.2024

pipenv — это замечательный проект, который призван упростить организацию рабочего процесса для Python-разработчиков. Он решает несколько наиболее актуальных для разработчика проблем (да, несколько, вопреки Unix-way). Этакий швейцарский нож для питонистов.

pipenv нельзя рассматривать как замену pip , скорее это надстройка над pip . Но даже PyPA всерьёз рекомендует рассмотреть pipenv для управления зависимостями приложений, что как минимум означает, что проект хорошо зарекомендовал себя в сообществе.

Изначальный автор проекта — Кеннет Рейц (Kenneth Reitz) — он ещё и автор requests и множества других проектов "for humans", очевидно, вдохновлялся пакетными менеджерами из других экосистем, такими как npm (JavaScript) и bundler (Ruby), так что если вы когда-то пользовались этими инструментами, то можете заметить множество параллелей.

В названии проекта кроются два основных его назначения:

pip — установка и управления зависимостями проекта;
env — создание и управление виртуальным окружением для проекта.

Грубо говоря, pipenv можно рассматривать как симбиоз утилит pip и venv (или virtualenv ), которые работают вместе, пряча многие неудобные детали от конечного пользователя.

Помимо этого pipenv ещё умеет вот такое:

автоматически находить интерпретатор Python нужной версии (находит даже интерпретаторы, установленные через pyenv и asdf !);
запускать вспомогательные скрипты для разработки;
загружать переменные окружения из файла .env ;
проверять зависимости на наличие известных уязвимостей.

Стоит сразу оговориться, что если вы разрабатываете библиотеку (или что-то, что устанавливается через pip , и должно работать на нескольких версиях интерпретатора), то pipenv — не ваш путь. Этот инструмент создан в первую очередь для разработчиков конечных приложений (консольных утилит, микросервисов, веб-сервисов). Формат хранения зависимостей подразумевает работу только на одной конкретной версии интерпретатора (это имеет смысл для конечных приложений, но для библиотек это, как правило, не приемлемо). Для разработчиков библиотек существует другой прекрасный инструмент — poetry .

Итак, начнём по порядку.

Установка

Как я писал в посте про виртуальные окружения, не стоит устанавливать пакеты в глобальный интерпретатор, поэтому предпочтительным способом установки является пакетный менеджер вашей ОС.

Например, на MacOS pipenv можно установить через brew :

А на Fedora Linux вот так:

На Ubuntu можно установить pipenv из специального PPA:

Во всех остальных случаях, в частности на Windows, самый простой способ — это установка в домашнюю директорию пользователя (опять же, см. пост про виртуальные окружения):

Теперь проверим установку:

Если вы получили похожий вывод, значит, всё в порядке.

При возникновении проблем с установкой, обратитесь к официальной документации. Если совсем беда, то напишите комментарий под этим постом, попробуем помочь 😊

Файлы pipenv

pipenv использует свой собственный формат файла для описания зависимостей проекта — Pipfile . Этот файл имеет формат TOML. В принципе его можно редактировать руками, но pipenv достаточно неплохо и сам умеет обновлять этот файл, когда вы просто работаете с утилитой через командную строку. Структуру этого файла рассмотрим чуть позже.

В паре с Pipfile идёт Pipfile.lock . Он имеет формат JSON и не предназначен для редактирования руками. Этот файл хранит контрольные суммы пакетов, которые вы устанавливаете в проект, что даёт гарантию, что развёрнутые на разных машинах окружения будут идентичны друг другу. pipenv автоматически обновляет контрольные суммы в этом файле, когда вы устанавливаете или обновляете зависимости. При развёртывании окружения pipenv сверит сохранённые контрольные суммы с фактически получившимися, и в случае чего уведомит вас, что развёртывание не удалось. Это очень важный плюс в копилку pipenv по сравнению с pip .

Оба этих файла можно и нужно сохранять в системе контроля версий (git).

Вообще, идею использовать два файла для описания зависимостей нельзя назвать новой. Здесь явно прослеживается параллель между Gemfile и Gemfile.lock из мира Ruby и package.json и package-lock.json из мира JavaScript. Все эти файлы имеют схожее назначение.

Использование

Инициализация проекта

Давайте создадим простой проект под управлением pipenv .

Создать новый проект, использующий конкретную версию Python можно вот такой командой:

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

После выполнения одной из этих команд, pipenv создал файл Pipfile и виртуальное окружение где-то в заранее определенной директории (по умолчанию вне директории проекта).

Это минимальный образец Pipfile . В секции [[source]] перечисляются индексы пакетов — сейчас тут только PyPI, но может быть и ваш собственный индекс пакетов. В секциях [packages] и [dev-packages] перечисляются зависимости приложения — те, которые нужны для непосредственной работы приложения (минимум), и те, которые нужны для разработки (запуск тестов, линтеры и прочее). В секции [requires] указана версия интерпретатора, на которой данное приложение может работать.

Очень полезно правильно разделять зависимости на "основные" и "разработческие". Это позволит уменьшить размер окружения при развёртывании на продакшн (например, размер Docker-образа). Кроме того, чем меньше в системе, работающей на продакшне, установлено пакетов, тем меньше потенциальных уязвимостей.

Если вам нужно узнать, где именно pipenv создал виртуальное окружение (например, для настройки IDE), то сделать это можно вот так:

Управление зависимостями через pipenv

Теперь давайте установим в проект первую зависимость. Делается это при помощи команды pipenv install :

Давайте посмотрим, что поменялось в Pipfile (здесь и дальше я буду сокращать вывод команд или содержимое файлов при помощи . ):

В секцию [packages] добавилась зависимость requests с версией * (версия не фиксирована).

А теперь давайте установим зависимость, которая нужна для разработки, например, восхитительный линтер flake8 , передав флаг --dev в ту же команду install :

Теперь можно увидеть всё дерево зависимостей проекта при помощи команды pipenv graph :

Это бывает полезно, чтобы узнать, что от чего зависит, или почему в вашем виртуальном окружении есть определённый пакет.

Также, пока мы устанавливали пакеты, pipenv создал Pipfile.lock , но этот файл длинный и не интересный, поэтому показывать содержимое я не буду.

Удаление и обновление зависимостей происходит при помощи команд pipenv uninstall и pipenv update соответственно. Работают они довольно интуитивно, но если возникают вопросы, то вы всегда можете получить справку при помощи флага --help :

Управление виртуальными окружениями

Давайте удалим созданное виртуальное окружение:

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

Эта команда на основе Pipfile.lock воссоздаст точно то же самое виртуальное окружение, что и у других разработчиков проекта.

Если же вам не нужны dev-зависимости (например, вы разворачиваете ваш проект на продакшн), то можно не передавать флаг --dev :

Чтобы "войти" внутрь виртуального окружения, нужно выполнить:

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

Есть и другой способ запускать что-то внутри виртуального окружения без создания нового шелла:

Переменные окружения

Согласно идеологии 12-факторных приложений, конфигурацию принято хранить отдельно от кода, а лучше всего конфигурацию вообще хранить в переменных окружения (environment variables или env vars). Чтобы упростить работу с переменными окружения в процессе разработки, широкое айти-сообщество придумало сохранять их в специальный файл .env и загружать в шелл по мере необходимости. Такие файлы используются во множестве фреймворков, инструментов и экосистем. pipenv упрощает работу с переменными окружения в Python-проектах.

Давайте создадим файл .env и запишем туда какое-нибудь значение:

ВАЖНО: файл .env может содержать пароли для подключения к СУБД или токены для доступа к внешним сервисам. Такие данные никогда не должны попадать в git.

Давайте напишем небольшой скрипт ( script.py ), который будет использовать эту переменную окружения:

Попробуем запустить его без использования pipenv :

Скрипт вместо секретного значения вывел None , потому что переменная окружения так и осталась просто лежать в файле, и никак не повлияла на работу скрипта. А теперь запустим этот же скрипт через pipenv :

pipenv увидел файл .env и автоматически загрузил переменные из него. Скрипт вывел то значение, которое мы и ожидали увидеть. Команда pipenv shell тоже подгружает переменные окружения из файла.

Запуск скриптов

Часто в процессе разработки встречаются повторяющиеся задачи. Если вы работаете в команде, то ваши коллеги наверняка тоже с ними сталкиваются. Было бы разумно сохранить/задокументировать где-то команды, нужные для решения этих повторяющихся задач, чтобы их было проще найти и чтобы они всегда выполнялись одинаково. Можно, конечно, использовать обычные .sh файлы, но у pipenv тоже есть инструмент, который может в этом помочь, и даже лучше.

Допустим, что вы регулярно запускаете проверку кода flake8 , но с указанием дополнительных флагов, например, вам не нужно проверять определенную директорию, а так же вы хотите пропускать один вид ошибок (правильнее было бы просто сохранить эти параметры в конфигурационный файл, но примера ради будем передавать всё через командную строку):

Отредактируем Pipfile , создав там секцию [scripts] со следующим содержимым:

Теперь тот же самый скрипт можно запустить при помощи команды:

В качестве бонуса pipenv автоматически подгрузит переменные окружения, так что таким же образом можно выполнять и скрипты, которые зависят от конфигурации проекта (миграции БД, очистки кэшей, удаление временных файлов, да что угодно).

Распространённые проблемы

Перечислю проблемы, с которыми я сталкивался в процессе работы с pipenv .

Лишние зависимости в виртуальном окружении

Бывает, что кроме перечисленных в Pipfile и Pipfile.lock зависимостей в виртуальном окружении установлены и другие пакеты. Такое может случиться, например, при переключении между ветками в git, где в Pipfile.lock находятся разные зависимости. Или, банально, если внутри виртуального окружения вы установите что-то через pip помимо pipenv .

Чаще всего вам будет безразлично, есть в виртуальном окружении какие-то лишние пакеты или нет, но иногда такие лишние пакеты влияют на работу приложения. Пример из моей практики: ORM orator будет использовать тот драйвер для подключения к MySQL, который первым найдёт в виртуальном окружении, поэтому если вы хотите использовать pymysql , то нужно убедиться, что в виртуальном окружении нет MySQLdb (он приоритетнее).

Нужно учитывать, что команда pipenv sync --dev только доустанавливает пакеты в виртуальное окружение, но не удаляет оттуда уже установленные. Поэтому, если вам нужно обеспечить отсутствие в виртуальном окружении лишних пакетов, то приходится удалять его полностью и создавать заново:

Пререлизные зависимости

По умолчанию pipenv игнорирует нестабильные альфа- и бета-версии пакетов, и устанавливает только стабильные. Может случиться так, что вам нужно установить пререлизную версию пакета, например, автоформаттер black , который на данный момент всё ещё не имеет стабильных релизов вообще:

Команда завершилась ошибкой, но pipenv предлагает воспользоваться опцией --pre , чтобы установить пререлизную зависимость. Избегайте искушения сделать так.

Что произойдёт, если всё-таки рискнуть:

На первый взгляд, всё хорошо. Но давайте заглянем в Pipfile :

Там появилась директива allow_prereleases = true , которая глобально меняет поведение pipenv и разрешает ему устанавливать пререлизные версии вообще любых зависимостей, а не только той, которую вы хотели установить. Если у вас в Pipfile не ограничены версии зависимостей (как у requests = "*" ), то следующий запуск pipenv install или pipenv update может принести в ваш проект кучу нестабильных зависимостей. Не факт, что приложение это переживёт.

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

Если же вы уже попались в эту ловушку pipenv , то просто отредактируйте Pipfile и либо удалите оттуда директиву allow_prereleases вообще, либо поменяйте значение на false . После этого можно спать спокойно.

Мердж-конфликты в Pipfile.lock

Когда в двух параллельных ветках происходит установка или обновление пакетов, либо просто редактируется Pipfile , то при слиянии этих веток обязательно произойдет конфликт в Pipfile.lock . Git добавит в этот файл маркеры конфликтов, после чего, само собой, он перестает быть валидным JSON. В таких случаях pipenv просто превращается в тыкву и ничего не может сделать:

План выхода из такой ситуации следующий: 1. Не пытайтесь осознанно решать конфликты в Pipfile.lock вручную, всё равно не сможете; pipenv сам создал этот файл, вот пусть сам и разбирается. 2. Разрешите конфликт в любую сторону, главное, чтобы в итоге получился валидный JSON. 3. Пересоздайте Pipfile.lock заново:

Флаг --keep-outdated позволяет избежать лишних обновлений версий — вы ведь просто хотите разрешить конфликты, а не обновить все пакеты, верно? Тем не менее, pipenv может вас проигнорировать, и всё равно обновить некоторые пакеты, будьте к этому готовы (это известный баг).

Статус проекта: пациент скорее мертв, чем жив, но надежда есть

Стоит отметить, что после какой-то драмы в сообществе, изначальный автор (Kenneth Reitz) покинул проект (и вообще все свои проекты), и проект перешёл в общественное достояние. Любые такие конфликты всегда плохо сказываются на успехе проекта, и pipenv , определенно, переживает сейчас не лучшие времена. На данный момент последний релиз был 26 ноября 2018 года. За полтора года накопилось большое количество незарелиженных баг-фиксов, что говорит о проблемах с поддержкой проекта.

Несмотря на это, я всё равно рекомендую присмотреться к pipenv , потому что он действительно хорош. Недавно проект стал проявлять признаки жизни, и я очень надеюсь, что всё с ним будет хорошо. По-моему, это очень важный для экосистемы Python проект.

Обновление от 30 мая 2020: pipenv наконец выпустил долгожданный релиз 2020.5.28 .

Причины ошибки «Не является внутренней или внешней командой» при выполнении команд в командной строке Windows 10 и Windows 11

Для того, чтобы понять суть ошибки, давайте рассмотрим, что происходит при выполнении команды в командной строке, в качестве примера будем использовать такой код:

В случае, если «команда» является собственной встроенной командой консоли (в качестве примера — cls), она выполняется с заданными параметрами.
Если «команда» — это какой-то файл .exe, .cmd, .bat или иной, например, pip, python или adb, выполняется попытка его запуска из расположения, где запущена командная строка (выделено на изображении ниже) или из расположений, добавленных в системную переменную PATH (о которой поговорим подробнее далее). При удачном запуске и правильно переданных параметрах команда выполняется.

Отсюда следуют наиболее распространённые причины появления ошибки при выполнении команды:

Самая распространённая причина — отсутствие исполняемого файла в папке, где запущена командная строка и в папках, содержащихся в PATH.
Ошибки при написании команды: при ошибке в имени файла, он не будет найден, что и приведёт к указанной ошибке.
Файл отсутствует где-либо, например, вы пробуете использовать telnet, в то время, когда соответствующий компонент Windows не установлен.
Редко — запускаемый через командную строку файл действительно не является исполняемой программой: изначально сам по себе или из-за повреждений.

Теперь о том, что делать в рассматриваемой ситуации.

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

Переход к папке с исполняемым файлом в командной строке

Если выполнение команды требуется не на регулярной основе, достаточно перейти в командной строке в папку, содержащую нужный файл, делается это следующим образом:

Например, мы знаем, что python.exe для последней версии Python на момент написания этой статьи располагается в папкеpip.exe — там же во вложенной папке Scripts (если окажется не ясным, как попасть в эту папку, процесс показан в видео ниже), adb.exe — где-то в папке с platform-tools и так далее. Скопируйте этот путь, сделать это можно из адресной строки проводника.
Если командная строка запущена на том же диске, где находится нужный исполняемый файл, введите команду вида:
Если командная строка запущена на диске C:, а исполняемый файл находится на другом диске, то перед 2-м шагом используйте команду вида (здесь D меняем на нужную букву диска) D: с последующим нажатием Enter.
Введите нужную команду, которая ранее сообщала об ошибке — теперь она должна выполниться успешно.

Добавление папки с программой в системную переменную среды PATH

В случае, когда использование команд требуется регулярно, например, для git, разумным будет добавить папку с этим исполняемым файлом в PATH, чтобы затем в любой момент времени выполнять команды, независимо от того, в какой папке открыта командная строка:

Примечание: если ошибка возникает при использовании команд python, обратите внимание, что при первоначальной установке вам предложат добавить необходимые пути в PATH (отметка Add Python to PATH), то же самое часто бывает и при установке других программ:

Установка недостающих компонентов

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

Вы пробуете использовать команды telnet, но не зашли в Панель управления —Программы и компоненты — Включение или отключение компонентов Windows и не включили «Клиент Telnet».
Запускаете команды pyinstaller, но предварительно не установили его командой pip install pyinstaller
Пробуете использовать команды adb.exe, но не установили необходимые компоненты Android SDK Platform Tools.

Аналогичная ситуация может быть и для многих других, не входящих в стандартную поставку Windows 10 и Windows 11 компонентов, например, java.

Если ошибка возникает при запуске системных инструментов Windows

Видео инструкция

Надеюсь, статья и видео помогли разобраться с проблемой и помогли в её решении. Остаются вопросы? — задавайте их в комментариях, я постараюсь ответить.

Я новичок в разработке Python и пытаюсь использовать pipenv. Я выполнил команду pip install pipenv , которая успешно выполнилась:

Проверьте /usr/local/bin/pipenv - оно есть? Является ли /usr/local/bin в вашей $PATH ? Та же проблема: успешно собран pipenv, но нет никаких признаков папки pipenv в / usr / local / bin.

Это происходит потому, что вы не устанавливаете его глобально (в масштабе всей системы). Чтобы он был доступен у вас, path вам необходимо установить его sudo , например:

Это дает мне каждый раз новую среду рабочего стола. @michael У вас лучший ответ в комментарии. Позор! Опубликовать как ответ человек @michael, это единственное, что у меня сработало, большое спасибо! @michael Спасибо за ответ. Подтверждено, что это работает.

Это исправило это для меня:

Сработало отлично! Вы случайно знаете, что означают эти команды (-H и -U)? @ Babbz77 Параметр -H (HOME) для параметра sudo требует, чтобы политика безопасности установила для переменной среды HOME домашний каталог целевого пользователя (по умолчанию root), как указано в базе данных паролей. -U для pip install обновляет все указанные пакеты до последней доступной версии. Обработка зависимостей зависит от используемой стратегии обновления. Большое вам спасибо, я много боролся, но ваш ответ спас меня. Это должен быть ответ. Работает отлично. Я искал какое-то время. Спасибо

Если вы выполнили установку пользователем, вам нужно добавить нужную папку в вашу PATH переменную.

Это было полезно, поскольку мне нужно было запустить pipenv run , и инструкции по установке говорили мне об этом. Вы должны проверить, существует python3 -m site ли каталог --user-base!

Надеюсь, это поможет тебе.

спасибо, почему мне нужно включать python -m каждый раз, когда я запускаю pipenv?

У меня pipenv такая же проблема с Mac OS X 10.13 High Seirra, другой Mac работает нормально. Я использую Heroku для развертывания серверов Django, некоторые из них - в версии 2.7, а некоторые - в версии 3.6. Итак, мне нужны и 2.7, и 3.6. Когда HomeBrew устанавливает Python, он сохраняет python точки до 2.7 и python3 3.6.

Проблема может быть связана с $ pip install pipenv . Я проверил / usr / local / bin, а pipenv там нет. Итак, я попробовал полностью удалить:

Затем переустановите и теперь работает:

РЕБЯТА OSX, ЗДЕСЬ .

Как ответил @charlax (для меня лучший), вы можете использовать более динамическую команду для установки PATH, но для пользователей Mac это не может работать , иногда ваш путь USER_BASE, полученный с сайта, неверен, поэтому вам нужно узнать, где ваш установка python есть.

вы получите символическую ссылку, тогда вам нужно будет найти символическую ссылку на источник.

(это ../../../ означает корень)

Итак, вы нашли путь Python ( /Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6 ), тогда вам просто нужно ввести

/ .bashrc следующим образом:

Я установил python3 через Homebrew. Когда я запустил which python3 вывод, /Cellar/python/3.7.7/bin/python3 я назначил его своему PATH, но по-прежнему pipenv не найден. Любая идея?

Где Python хранит пакеты

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

Глобальные пакеты сайтов - это место, где Python устанавливает пакеты, которые будут доступны всем пользователям и всем приложениям Python в системе. Вы можете проверить глобальный пакет сайта с помощью команды

Например, в Linux с Python 3.7 путь обычно

Пользовательские пакеты сайта - это место, где Python устанавливает пакеты, доступные только вам. Но пакеты по-прежнему будут видны всем проектам Python, которые вы создаете. Вы можете пройти путь с

В Linux с Python 3.7 путь обычно

Использование Python 3.x

В большинстве Linux и других Unix Python 2 и Python 3 обычно устанавливаются бок о бок. Исполняемый файл Python 3 по умолчанию почти всегда python3 . pip может быть доступен как один из следующих, в зависимости от вашего дистрибутива Linux

Избегайте использования pip с sudo ! Да, это наиболее удобный способ установки пакетов Python, и исполняемый файл доступен по адресу /usr/local/bin/pipenv , но это также означает, что конкретный пакет всегда виден всем пользователям и всем проектам Python, которые вы создаете. Вместо этого используйте пакеты сайта для каждого пользователя с --user

pipenv доступно на

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

Если вы используете Homebrew'ed Python, pip install --user он отключен. Глобальный сайт-пакет находится по адресу

и вы можете безопасно установить здесь пакеты Python. Python 3.y также ищет модули в:

По причинам устаревания Python установлен в C:\Python37 . Исполняемый файл Python обычно называется py.exe , и вы можете запускать его pip с py -m pip .

Пакеты глобальных сайтов установлены в

Поскольку вы обычно не используете свои устройства Windows совместно, можно также установить пакет глобально.

pipenv теперь доступен на

Я не рекомендую устанавливать пакеты Python в Windows с помощью --user , потому что каталог сайта пользователя по умолчанию находится в вашем перемещаемом профиле Windows

Перемещаемый профиль используется в службах терминалов (удаленный рабочий стол, Citrix и т. Д.), А также при входе / выходе из корпоративной среды. Медленный вход, выход из системы и перезагрузка в Windows могут быть вызваны большим перемещаемым профилем.

Глобальная установка pipenv может иметь неблагоприятный эффект, поскольку перезаписывает глобальную / управляемую системой установку pip, что приводит к ошибкам импорта при попытке запустить pip.

Вы можете установить pipenv на уровне пользователя:

pip install --user pipenv

sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

а затем сделал следующее:

mkdir /home/username/.local . если его еще нет

Убедитесь, что экспорт вступил в силу (укусил меня однажды во время этого процесса):

Затем я запустил программу, pip install --user pipenv и все было хорошо. Затем я мог запустить pipenv из CLI, и он не перезаписал глобальный / управляемый системой модуль pip. Конечно, это зависит от пользователя, поэтому вы хотите убедиться, что вы устанавливаете pipenv таким образом, работая в качестве пользователя, которого вы хотите использовать pipenv.

Я новичок в разработке Python и пытаюсь использовать pipenv. Я выполнил команду pip install pipenv , которая успешно прошла:

Это происходит потому, что вы не устанавливаете его глобально (для всей системы). Чтобы он был доступен в вашем path , вам необходимо установить его, используя sudo , например так:

Вы можете установить pipenv с помощью pipsi .

В Mac OS X Catalina, похоже, идет по пути Linux. Используя любой из:

По сути, устанавливает pipenv здесь:

Но это не исполняемый файл и поэтому никогда не найден. Единственное, что сработало для меня, было

Похоже, это приводит к появлению файла __init__.py в указанном выше каталоге, в котором есть содержимое, позволяющее правильно выставить команду pipenv .

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

Пакет pipenv определенно выглядит довольно придирчивым.

У меня та же проблема с pipenv в Mac OS X 10.13 High Seirra, другой Mac работает просто отлично. Я использую Heroku для развертывания своих серверов Django, некоторые в 2.7, а некоторые в 3.6. Итак, мне нужны оба 2.7 и 3.6. Когда HomeBrew устанавливает Python, он сохраняет python точек на исходном 2.7, а python3 указывает на 3.6.

Возможно, проблема связана с $ pip install pipenv . Я проверил / usr / local / bin и pipenv там нет. Итак, я попытался полностью удалить:

Затем переустановите и работайте сейчас:

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

Вы можете установить pipenv на уровне пользователя:

pip install --user pipenv

sudo python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

И затем сделал следующее:

mkdir /home/username/.local . если он еще не существует

Убедитесь, что экспорт вступил в силу (побил меня один раз во время этого процесса):

Затем я запустил pip install --user pipenv и все было хорошо. Затем я мог запустить pipenv из CLI, и он не переписал глобальный / управляемый системой модуль pip. Конечно, это зависит от пользователя, поэтому вы должны убедиться, что вы устанавливаете pipenv таким образом, работая как пользователь, которому вы хотите использовать pipenv.

Для пользователей окон это может быть связано с конфликтом установки с virtualenv. Для меня это сработало, когда я сначала удалил virtualenv и pipenv, а затем установил только pipenv.

Теперь pipenv install xxx работал на меня

Где Python хранит пакеты

Прежде чем перейти к команде, которая установит pipenv , стоит понять, где pip устанавливает пакеты Python .

Глобальные пакеты сайта - это место, где Python устанавливает пакеты, которые будут доступны всем пользователям и всем приложениям Python в системе. Вы можете проверить глобальный пакет сайта с помощью команды

Например, в Linux с Python 3.7 путь обычно

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

В Linux с Python 3.7 путь обычно

Использование Python 3.x

В большинстве Linux и других Unix обычно Python 2 и Python 3 устанавливаются параллельно. Исполняемый файл Python 3 по умолчанию почти всегда python3 . pip может быть доступен в следующих случаях, в зависимости от вашего дистрибутива Linux

Избегайте использования pip с sudo ! Да, это наиболее удобный способ установки пакетов Python, и исполняемый файл доступен в /usr/local/bin/pipenv , но это также означает, что определенный пакет всегда виден всем пользователям и всем создаваемым вами проектам Python. Вместо этого используйте пакеты сайтов для каждого пользователя вместо --user

pipenv доступен на

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

Если вы используете Homebrew'ed Python, pip install --user отключен. Глобальный сайт-пакет находится по адресу

И вы можете безопасно установить пакеты Python здесь. Python 3.y также ищет модули в:

По устаревшим причинам Python установлен в C:\Python37 . Исполняемый файл Python обычно называется py.exe , и вы можете запустить pip с py -m pip .

Пакеты глобального сайта установлены в

Так как вы обычно не делитесь своими устройствами с Windows, также можно установить глобально пакет

pipenv теперь доступен на

Я не рекомендую устанавливать пакеты Python в Windows с --user , потому что каталог пользовательских пакетов сайта по умолчанию находится в вашем роуминговом профиле Windows

Перемещаемый профиль используется в службах терминалов (удаленный рабочий стол, Citrix и т. Д.), А также при входе / выходе из системы в корпоративной среде. Медленный вход в систему, выход из системы и перезагрузка в Windows могут быть вызваны большим перемещаемым профилем.

OSX ПАРНИ, ЗДЕСЬ ЗДЕСЬ .

Как ответил @charlax (для меня лучший), вы можете использовать более динамичную команду для установки PATH, buuut для пользователей Mac, это не может работать , иногда ваш путь USER_BASE, полученный с сайта, неверен, поэтому вам нужно выяснить, где находится ваша установка на python.

Вы получите символическую ссылку, затем вам нужно найти символическую ссылку источника.

(это ../../../ означает root)

Итак, вы нашли путь к питону ( /Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6 ), тогда вам просто нужно вставить в

После установки pipenv ( sudo pip install pipenv ) я продолжал получать ошибку «Команда не найдена» при попытке выполнить команду pipenv shell .

Я наконец исправил это с помощью следующего кода:

Если вы выполнили пользовательскую установку, вам нужно добавить нужную папку в переменную PATH .

Читайте также: