Whl python установка linux

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 на колёсах. И это вроде даже работает, и, возможно, стоит потраченного времени.

Источник

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

У меня возникли проблемы с установкой пакета Python (в частности, JPype1 0.5.7) на моей машине Windows, и я хотел бы установить его с двоичными файлами окна Кристофа Голке. (Что, по моему опыту, облегчило большую часть суеты для многих других установок пакетов.)

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

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

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

14 ответов

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

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

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

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

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

Я нахожусь в той же лодке, что и ОП.

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

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

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

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

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

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

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

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

проверьте pip версия:

если он показывает 6.x серия, поддержка колеса.

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

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

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

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

PS pip.предполагается, что exe находится в пути.

обновление:

(1) Те можно совместить в одном строка:

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

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

посмотреть мои блоге для сведения.

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

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

Модуль

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

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

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

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

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

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

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

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

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

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

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

на MacOS, с pip установлен через MacPorts в MacPorts python2.7, мне пришлось использовать решение @Dunes:

здесь python был заменен MacPorts python в моем случае, который является python2.7 или python3.5 для меня.

на -m опция «запустить модуль библиотеки как скрипт» в соответствии с manpage.

(я ранее работать sudo port install py27-pip py27-wheel установить pip и wheel сначала в мою установку python 2.7.)

Источник