Как и кто должен указывать колесо как Python зависимость пакета?

Question

Я пишу исходный пакет (не полностью упакованный модуль, но некоторые сценарии с зависимостями) для установки и выполнения в приложении фреймворка (в частности, обслуживающий контейнер TensorFlow от Amazon SageMaker - работает Python 3.5).

Одна из моих зависимостей - matplotlib, которая, в свою очередь, нуждается в kiwisolver, который содержит компоненты C ++.

Похоже, мой целевой контейнер не имеет wheel устанавливается по умолчанию, потому что, когда я предоставляю только requirements.txt файл, я получаю сообщение об ошибке, описанное в «Почему python setup.py говорит неверную команду« bdist_wheel »в Travis CI?» .

Я думаю, что я получил его, поставив вместо него setup.py, с setup_requires=["wheel"], как рекомендовано в ответах на этот вопрос Travis CI.

Моя Python упаковка -fu слабая, поэтому мой вопрос: кто должен указать эту зависимость, потому что кажется, что это не я?

• Должен ли kiwisolver рекламировать то, что ему нужно wheel?
• фреймворковое приложение / среда, устанавливающая модули пользовательского кода через requirements.txt, имеет неявный контракт, чтобы сделать wheel доступным в среде, по какой-то причине в духе упаковки Python?
• Может быть, он действительно включен я должен знать, что, поскольку я косвенно потребляю такой модуль, как kiwisolver, мой пакет требует wheel для настройки, а прямой pip install -r requirements.txt не будет работать?

Еще лучше, если кто-нибудь сможет объяснить меняется ли этот ответ при PEP 518 и при амортизации setup_requires: S

Answer 1

Обычно wheel можно рассматривать как зависимость время сборки , а не зависимость время установки . Но на самом деле wheel - это просто способ распространения Python проектов (библиотек или приложений), поэтому обычно это не является обязательной зависимостью.

В одной системе, которая собирает библиотеку ( kiwisolver ), может потребоваться установка инструмента wheel . Но если я не ошибаюсь, в последних версиях pip уже имеется wheel , так что в настоящее время часто нет необходимости устанавливать его явно.

Во многих случаях колеса уже доступны для PyPI . Но иногда нет колес , совместимых с целевой системой (Python версия интерпретатора, операционная система, загрузка процессора). В вашем случае kiwisolver имеет широкий диапазон колес , доступных, но не для Python 3,5 .

Похоже, система, которую вы хотите установить kiwisolver , не совместима ни с одним из колес , доступных на PyPI . Так что pip нужно строить локально. Обычно pip сначала пытается построить колесо , но, насколько я знаю, это не прерывает сделки, если колесо не может быть построено, тогда pip обычно просто продолжается и устанавливает проект, не переходя к промежуточному шагу wheel .

Но все же pip должен иметь возможность build библиотека, для которой могут потребоваться некоторые компиляторы C / C ++ или для выполнения других необычных условий в локальной системе. Вот почему распределять библиотеки как wheel очень удобно, поскольку шаг build уже сделан.

Так что, с моей точки зрения, нет действительно нужно объявить wheel как зависимую или установить wheel , если они на самом деле не хотят создавать wheel . Но wheel на самом деле является лишь промежуточным необязательным шагом. Это способ распространения Python проектов (библиотек или приложений). Я не вижу абсолютной необходимости для добавления колеса к setuptools 'setup_requires (что устарело или близко к нему) ) или pyproject.toml build-system.requires, это больше (очень распространенное и почти стандартное) удобство.

Что бы я делал в вашей ситуации?

• Перед установкой из файла requirements.txt, который содержит kiwisolver (прямо или косвенно), либо убедитесь, что pip обновлен, либо явно установите wheel , и:
  • Используйте версию Python, для которой колеса уже доступны на PyPI .
  • Если вы хотите остаться на Python 3.5 :
    • Убедитесь, что целевая система способна сама собрать kiwisolver (возможно, для этого требуется компилятор C / C ++ плюс некоторые другие нативные библиотеки).