Как установить whl python windows

Проблемы с установкой пакета Python (в частности, JPype1 0.5.7) на компьютере с Windows и его решение.

Christoph Gohlke раньше использовал файлы .exe, но сейчас файлы .whl.

Как установить файлы .whl?

Решения

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

Укажите текущий каталог файла при вызове pip из командной строки.
Например, чтобы установить ad3‑2.2.1‑cp38‑cp38‑win_amd64.whl :

• Откройте папку, где находится файл .whl
• Откройте командную строку с текущим каталогом.
  1. Удерживайте кнопку Shift на клавиатуре, нажмите правую кнопку мыши, выберите в контекстном меню «Командная строка» или «PowerShell»
  2. Или наберите команду cmd в поле с адресом папки в File Explorer
• Выполните команду pipe с указанием файла .whl.
  Например:
  Или, с указанием полного пути файла (файл .whl лежит в папке C:\src\ad3‑2.2.1‑cp38‑cp38‑win_amd64.whl):

Если команду pip не распознается, вы можете найти файл pip.exe в каталоге «Scripts», из которого был установлен python.
Если pip не установлен, эта страница может вам помочь: Как установить pip в Windows?

Если предложенное выше не помогает, ниже список команд и советов:

• Если версия выше 6.x , значит поддержка .whl должна быть
• Добавьте Python\Scripts переменную PATH

FAQ: Установка библиотек для Python

Инструкция по установке библиотек для python

Введение
Установка библиотек на всех платформах (windows, linux, macos) осуществляется одинаково, поэтому все описанное ниже вы сможете повторить на любой платформе.
Есть 2 способа установить библиотеку:

• автоматизированный — при помощи утилиты pip, она сама подберет необходимую версию библиотеки, скачает её с pypi и установит;
• ручной — необходимо вручную скачать нужную версию библиотеки и установить.

Все эти способы установки мы рассмотрим ниже.

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

Примеры в данной инструкции были сделаны в windows 10 и python 3.6.4 x64

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

• имя пользователя должно быть написано на латинице (это одно из ограничений windows);
• в переменной окружения path должен быть путь до папки с python и до папки Scripts (которая располагается в папке с python);
• python должен быть установлен «для всех пользователей», то есть установлен в «Program Files», либо в другую папку находящуюся в корне диска С.
  Идеальным вариантом будет создать в корне диска C папку bin и устанавливать туда всё необходимое для разработки. Такой подход спасет от разных
  неприятных недоразумений, связанных с ограничениями некоторых инструментов.

Вы можете настроить все вручную, либо провести правильную установку python, как это сделать будет показано рассказано в разделе «Правильная установка python в windows».

Автоматизированная установка
Автоматизированная установка проводится при помощи утилиты pip. Она сама подбирает необходимую версию библиотеки с https://pypi.python.org/pypi и устанавливает ее.
Данный способ подходит для 90% случаев, потому что практически все библиотеки для python размещаются на pypi. Чтобы воспользоваться pip нужно выполнить 1 простую команду:

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

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

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

1. Скачать архив с библиотекой
2. Перейти в разархивированную папку командой cd
3. Выполнить команду

При установке библиотеки из whl файла необходимо:

1. Выбрать whl который совместим с вашей ОС и установленным python`ом.
   Определить для какого интерпретатора и какой ОС собран whl очень просто по его имени.
   Название whl в общем виде: —(-)?-——.whl .
   • distribution — название дистрибутива (‘django’, ‘pyramid’ и т д);
   • version — версия дистрибутива (1.0 и т д);
   • build tag — номер сборки, его указывать не обязательно;
   • language implementation and version tag — указывает для какой версии python написана библиотека (‘py27’, ‘py2’, ‘py3’);
   • abi tag — указывает с какой версией python совместим дистрибутив (‘cp33’, ‘cp36’, ‘none’);
   • platform tag — тег указывающий целевую платформу (‘win’, ‘manylinux1’, ‘macosx’, ‘any’).

   Например, для python-3.6.4-amd64.exe, нужно скачивать — -cp36-cp36m-win_amd64.whl .
   Рассмотрим больше примеров:

   • PyQt5-5.6-cp35-none-win_amd64.whl — подходит для 64-битного python 3.5 установленного в windows
   • matplotlib-2.1.2-cp36-cp36m-win32.whl — подходит для 32-битного python 3.6 установленного в windows
   • requests-2.18.4-py2.py3-none-any.whl — подходит для python 2 и 3, разрядность интерпретатора не имеет значения, подходит для всех ОС
2. Установить библиотеку командой

Иногда бывает сложно найти whl подходящий для Вашего интерпретатора и ОС, если такая ситуация возникла можно поискать библиотеку сайте https://www.lfd.uci.edu/

gohlke/pythonlibs/.
Там регулярно выкладываются актуальные версии популярных библиотек для различных версий python.

Правильная установка python в windows

Чтобы правильно установить python действуйте как показано на скриншотах, представленных ниже:

Как установить пакет Python с файлом .whl?

У меня проблемы с установкой пакета Python на мой компьютер с Windows, и я хотел бы установить его с помощью бинарных файлов Christoph Gohlke’s Window. (Который, по моему опыту, облегчил большую часть суеты для многих других установок пакетов). Однако доступны только файлы .whl.

Но как мне установить .whl файлы?

• Я нашел документы за рулем , но они не кажутся такими простыми в объяснении, как устанавливать файлы .whl.
• Этот вопрос является дубликатом этого вопроса , на который не был дан прямой ответ.

Я просто использовал следующее, что было довольно просто. Сначала откройте консоль, затем перейдите к тому месту, где вы скачали свой файл, например some-package.whl, и используйте

Примечание: если pip.exe не распознан, вы можете найти его в каталоге «Scripts», откуда был установлен python. Если pip не установлен, эта страница может помочь: Как установить pip в Windows?

Примечание: для пояснения.
Если вы копируете *.whl файл на локальный диск (например, C: \ some-dir \ some-file.whl ), используйте следующие параметры командной строки:

Во-первых, убедитесь, что вы обновили пип, чтобы включить поддержку колес:

Затем для установки с колеса укажите каталог, в который загружается колесо. Например, чтобы установить package_name.whl :

Я в той же лодке, что и ОП.

С помощью командной строки Windows из каталога:

Перейдя в каталог, в котором находился whl, он просто сообщает мне, что pip не распознан. Возвращаясь к C:\Python34\Scripts> , затем используя полную команду, указанную выше, укажите местоположение «где / его / загружено» Requirement ‘scikit_image-. -win32.whl’ looks like a filename, but the filename does not exist .

Поэтому я сбросил копию .whl в Python34 / Scripts, снова выполнил ту же самую команду (при этом —find-links= все еще переходя в другую папку), и на этот раз она сработала.

На сайте великого Кристофа Гольке есть несколько версий файлов.

При установке колес с этого сайта я считаю важным сначала запустить его из консоли Python:

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

Вы должны запустить pip.exe из командной строки на моем компьютере. Я печатаю C:/Python27/Scripts/pip2.exe install numpy

В Windows вы не можете просто обновить с помощью pip install —upgrade pip , потому что pip.exe он используется, и при его замене возникнет ошибка. Вместо этого вы должны обновить pip как это:

Затем проверьте pip версию:

Если это показывает 6.x серию, есть поддержка колеса.

Только тогда вы можете установить пакет с колесом так:

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

1) Запустите две команды в командной строке с правами администратора:

2) Кроме того, их можно скопировать в wheel.bat файл и выполнить с помощью флажка «Запуск от имени администратора» в свойствах.

PS pip.exe предполагается в PATH.

Обновить:

(1) Они могут быть объединены в одну строку:

(2) Синтаксис для файлов .bat немного отличается:

Также его вывод можно сделать более подробным:

см. мой блог для деталей.

РЕДАКТИРОВАТЬ: ЭТО НЕ ДЛИННЕЕ ЧАСТЬ PIP

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

Для получения дополнительной информации см. Это .

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

Вы можете скачать конкретный .whl пакет (колесо) с — https://www.lfd.uci.edu/

CD (Изменить каталог) на этот загруженный пакет и установить его вручную,
pip install PACKAGENAME.whl
например:
pip install ad3‑2.1‑cp27‑cp27m‑win32.whl

Единственный способ, которым мне удалось установить NumPy, был следующим:

Этот модуль

Выполнение команды из пути установки Python в PowerShell

PS .: Я установил его на Windows 10.

Вы можете установить .whl файл, используя pip install filename . Хотя, чтобы использовать его в этой форме, он должен находиться в том же каталоге, что и ваша командная строка, в противном случае укажите полное имя файла вместе с его адресом, как pip install C:\Some\PAth\filename .

Также убедитесь, что файл .whl той же платформы, что и вы, выполните команду a, python -V чтобы узнать, какую версию Python вы используете, и, если это win32 или 64, установите правильную версию в соответствии с ней.

Сначала я обновил пункт с помощью команды: pip install —upgrade pip затем я также установил колесо с помощью команды: pip install wheel и тогда он работал отлично.

Надеюсь, у вас это получится.

Новые пользователи Python в Windows часто забывают добавить каталог Python \ Scripts в переменную PATH во время установки. Я рекомендую использовать средство запуска Python и выполнить pip как скрипт с -m переключателем. Затем вы можете установить диски для конкретной версии Python (если установлено более одной), и каталог Scripts не обязательно должен находиться в PATH. Итак, откройте командную строку, перейдите (с помощью cd команды) к папке, где находится файл .whl, и введите:

Замените 3.6 на вашу версию Python или просто введите, -3 если нужная версия Python появляется первой в PATH. И с активной виртуальной средой py -m pip install your_whl_file.whl .

Конечно, вы также можете установить пакеты из PyPI, например:

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

Следуйте инструкциям, чтобы импортировать модуль

1. Убедитесь, что ваш файл .whl хранится в папке python 2.7 / 3.6 / 3.7 / . Первоначально, когда вы загружаете .whl файл, файл хранится в загруженной папке, я предлагаю изменить папку. Это облегчает установку файла.
2. Откройте командную строку и откройте папку, в которой вы сохранили файл, введя

3. Теперь введите команду, написанную ниже

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

Как только вы нажмете ввод, подождите несколько минут, и файл будет установлен, и вы сможете импортировать конкретный модуль.

Чтобы проверить, успешно ли установлен модуль, импортируйте модуль в режиме ожидания и проверьте его.

Python на колёсах

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm , который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат ‘яиц’ [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg’и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и ‘яиц’ в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как ‘яйца’ на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали ‘колёсами’ [wheels].

В дальнейшем предполагается, что все действия происходят в virtualenv-окружении.

Что за колесо?

Начнём с простого. Что представляют собой ‘колёса’ и чем они отличаются от ‘яиц’? Оба формата являются zip-файлами. Главная разница в том, что egg можно импортировать без распаковки, wheel же придётся распаковать. Хотя нет никаких технических причин, делающих ‘колёса’ неимпортируемыми, поддержка их прямого импорта никогда даже не планировалась.

Другое различие в том, что ‘яйца’ содержат скомпилированные байткод, а ‘колёса’ – нет. Главное преимущество этого в том, что нет необходимости создавать отдельные wheel’ы для каждой версии Python до тех пор, пока не придётся распространять слинкованные через libpython модули. Хотя в новых версиях Python 3 при использовании стабильного ABI даже это уже можно провернуть.

Однако wheel-формат тоже не лишен проблем, некоторые из которых он наследует от ‘яиц’. Например, бинарные дистрибутивы под Linux до сих пор неприемлемы для большинства из-за двух недостатков: Python сам по себе компилируется под Linux в разных формах, и модули линкуются с разными системными библиотеками. Первая проблема вызвана сосуществованием несовместимых версий Python 2: USC2 и USC4. В зависимости от режима компиляции меняется ABI. В настоящее время wheel (насколько я могу судить) не содержит информации о том, с каким режимом Unicode связана библиотека. Отдельная проблема в том, что дистрибутивы Linux меньше совместимы между собой, чем хотелось бы, и обстоятельства могут сложиться так, что сборка, скомпилированная под один дистрибутив, не будет работать на остальных.

Всё это выливается в то, что, вообще говоря, на данный момент бинарные ‘колёса’ нельзя загружать на PyPI как несовместимые с различными системами.

В дополнение ко всему этому wheel сейчас знает только две крайности: бинарные пакеты и пакеты, содержащие чистый python-код. Бинарные пакеты специфичны для Python ветки 2.x. Сейчас это не кажется большой проблемой, потому что цикл 2.x подходит к концу, и пакетов, собранных только для 2.7, хватит надолго. Но если бы вдруг речь пошла про Python 2.8, была бы интересна возможность заявить, что этот пакет не зависит от версии Python, но он содержит бинарники, поэтому он не может не зависеть от архитектуры.

Единственный случай, оправдывающий существование такого пакета – это когда он содержит распределенные библиотеки, загружаемые с ctypes из CFFI. Такие библиотеки не связаны через libpython и не зависимы от реализации языка (их можно использовать даже с pypy).

Но есть и светлая сторона: ничто не запрещает использовать бинарные wheel’ы в своих собственных однородных инфраструктурах.

Сборка колеса

Итак, теперь мы знаем, что такое wheel. Как сделать своё собственное ‘колесо’? Сборка из собственных библиотек – простейший процесс. Всё, что нужно – свежая версия setuptools и библиотека wheel . Как только они оба установлены, ‘колесо’ собирается следующей командой:

Wheel будет создан в директории пакета. Однако есть одна вещь, которой следует опасаться: распространение бинарников. По умолчанию собираемое ‘колесо’ (при условии, что в setup.py не используется никаких бинарных шагов) состоит из pure-python кода. Это значит, что даже если распространять .so , .dylib или .dll как часть своего пакета, полученное ‘колесо’ будет выглядеть платформо-независимым.

Решение этой проблемы – вручную реализовать Distribution из setuptools, скинув флаг чистоты в false :

Установка колеса

С использованием свежей версии pip ‘колесо’ ставится следующим образом:

Но что с зависимостями? Тут появляются некоторые сложности. Обычно одним из требований к пакету является возможность его установки даже без подключения к интернету. К счастью, pip позволяет отключать загрузку из индекса и устанавливать директорию, содержащую всё необходимое для установки. Если у нас есть wheel’ы для всех зависимостей необходимых версий, можно сделать следующее:

Таким образом будет установлена версия 1.0 пакета package в наше виртуальное окружение.

Колёса для зависимостей

Окей, но что, если у нас нет .whl для всех наших зависимостей? Pip в теории позволяет решить эту проблему использованием команды wheel . Это должно работать как-то так:

Эта команда выгрузит все пакеты, от которых зависит наш пакет, в указанную папку. Но есть пара проблем.
Первая состоит в том, что в команде в настоящий момент есть баг, который не выгружает зависимости, которые уже являются ‘колёсами’. Так что если зависимость уже доступна на PyPI в wheel-формате, она не будет загружена.

Это временно решается shell-скриптом, который вручную перемещает из кэша скачанные wheel’ы.

Вторая проблема чуть серьёзней: как pip найдет наш собственный пакет, если его нет на PyPI? Правильно, никак. Документация в таком случае рекомендует использовать не pip wheel package , а pip wheel -r requirements.txt , где requirements.txt содержит все необходимые зависимости.

Сборка пакетов c использованием DevPI

Такое временное решение проблемы зависимостей вполне применимо в простых ситуациях, но что делать, если есть множество внутренних python-пакетов, зависящих друг от друга? Такая конструкция быстро разваливается.

К счастью, в прошлом году Holker Krekel создал решение этой беды под названием DevPI, который по существу является хаком, эмулирующим работу pip с PyPI. После установки на компьютер DevPI работает как прозрачный прокси перед PyPI и позволяет pip-у устанавливать пакеты из локального репозитория. К тому же все пакеты, скачанные с PyPI, автоматически кэшируются, так что даже если отключить сеть, эти пакеты будут доступны для установки. И, в конце концов, появляется возможность загрузки своих собственных пакетов на локальный сервер, чтобы ссылаться на них так же, как и на хранящиеся в публичном индексе.

Я рекомендую установить DevPI в локальный virtualenv, после чего добавить ссылки на devpi-server и devpi в PATH .

После этого остаётся просто запустить devpi-server , и он будет работать до ручной остановки.

После запуска его необходимо единожды проинициализировать:

Так как я использую DevPI ‘для себя’, имена пользователя DevPI и системного пользователя совпадают. На последнем шаге создаётся индекс по имени проекта (при необходимости можно создать несколько).

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

Я размешаю эту команду в скрипт postactivate моего virtualenv для предотвращения случайной загрузки из неверного индекса.

Для размещения собственных wheel’ов в локальном DevPI используется утилита devpi :

Флаг —no-vcs отключает магию, которая пытается определить систему контроля версий и перемещает некоторые файлы в первую очередь. Мне это не нужно, так как в моих проектах распространяются файлы, которые я не включаю в VCS (бинарники, например).

Напоследок я настоятельно рекомендую разбить файлы setup.py таким образом, что PyPI их отвергнет, а DevPI примет, чтобы случайно не зарелизить свой код с помощью setup.py resease . Самый простой способ это сделать – добавить неверный классификатор PyPI:

Заворачиваем

Теперь всё готово для начала использования внутренних зависимостей и сборки собственных ‘колёс’. Как только они появятся, их можно заархивировать, загрузить на другой сервер и установить в отдельный virtualenv.
Весь процесс станет чуть проще, когда pip wheel перестанет игнорировать существующие wheel-пакеты. А пока приведенный выше shell-скрипт – не худшее решение.

В сравнении с ‘яйцами’

Сейчас wheel-формат более притягателен, чем egg. Его разработка активнее, PyPI начал добавлять его поддержку и, так как с ним начинают работать утилиты, он похож на лучшее решение. ‘Яйца’ пока что поддерживаются только easy_install, хотя большинство давно перешло на pip.

Я считаю, что сообщество Zope до сих пор крупнейшее из базирующихся на egg-формате и buildout. И я считаю, что если решение на основе ‘яиц’ в вашем случае применимо, его и стоит применять. Я знаю, что многие не используют eggs вовсе, предпочитая создавать virtualenv-ы, архивировать их и рассылать по разным серверам. Как раз для такого развёртывания wheels – лучшее решение, так как у разных серверов могут быть разные пути к библиотекам. Встречалась проблема, связанная с тем, что .pyc -файлы создавались на билд-сервере для virtualenv, а эти файлы содержат конкретные пути к файлам. С использованием wheel .pyc создаются после установки в виртуальное окружение и автоматически будут иметь корректные пути.

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