setuptools против distutils: почему distutils все еще существует?
Python имеет запутанную историю инструментов, которые могут быть использованы для упаковки и описания проектов: они включают distutils
в стандартной библиотеке, distribute
, distutils2
и setuptools
(а может и больше). Похоже, что distribute
и distutils2
были прекращены в пользу setuptools
, что оставляет два конкурирующих стандарта.
Насколько я понимаю, setuptools
предлагает гораздо больше опций (например, объявление зависимостей, тестов и т.д.), Чем distutils
, однако он не включен в стандартную библиотеку Python (пока?).
Руководство пользователя по упаковке Python [ 1 ] теперь рекомендует:
Используйте setuptools
для определения проектов и создания исходных распределений.
И объясняет:
Несмотря на то, что вы можете использовать чистые distutils
для многих проектов, он не поддерживает определение зависимостей от других проектов и пропускает несколько удобных утилит для автоматического заполнения метаданных пакета, которые предоставляются setuptools
. Находясь за пределами стандартной библиотеки, setuptools также предлагает более согласованный набор функций для различных версий Python, и (в отличие от distutils
), setuptools
будет обновлен для создания будущих стандартных форматов "Метаданные 2.0" во всех поддерживаемых версиях.
Даже для проектов, которые предпочитают использовать distutils
, когда pip устанавливает такие проекты непосредственно из исходного кода (а не из предварительно созданного файла колеса), он фактически строит ваш проект с использованием setuptools
.
Тем не менее, просмотр различных файлов проекта setup.py показывает, что это не является стандартом. Многие пакеты по-прежнему используют distutils
а те, которые поддерживают setuptools
часто смешивают setuptools
с distutils
например, выполняя резервный импорт:
try:
from setuptools import setup
except ImportError:
from distutils.core import setup
Затем последовала попытка найти способ написания установки, которая может быть установлена как setuptools
и distutils
. Это часто включает в себя различные способы проверки зависимостей, подверженных ошибкам, поскольку distutils
не поддерживает зависимости в функции настройки.
Почему люди все еще прилагают дополнительные усилия для поддержки distutils
- единственная причина, по которой setuptools
не входит в стандартную библиотеку? Каковы преимущества distutils
и есть ли недостатки в написании файлов setup.py, которые поддерживают только setuptools
.
Ответы
Ответ 1
Посмотрите на этот ТАК вопрос. Он очень хорошо объясняет все методы упаковки и может помочь до некоторой степени ответить на ваш вопрос: Различия между дистрибутивом, distutils, setuptools и distutils2?
Distutils по-прежнему является стандартным инструментом для упаковки в Python. Он включен в стандартную библиотеку (Python 2 и Python 3.0 до 3.3). Это полезно для простых дистрибутивов Python, но не имеет функций. Он представляет пакет Python distutils, который можно импортировать в ваш скрипт setup.py.
Setuptools был разработан для преодоления ограничений Distutils и не входит в стандартную библиотеку. Он представил утилиту командной строки под названием easy_install. Он также представил Python-пакет setuptools, который можно импортировать в сценарий setup.py, и Python-пакет pkg_resources, который можно импортировать в код для поиска файлов данных, установленных вместе с дистрибутивом. Один из его недостатков заключается в том, что он исправляет пакет Python distutils. Это должно хорошо работать с pip. Последняя версия была выпущена в июле 2013 года.
Итак, как вы можете видеть, setuptools предпочтительнее distutils, и я вижу, откуда возникает ваш вопрос, однако я не вижу, чтобы distutils терял поддержку в ближайшее время, поскольку, проще говоря, он используется во многих случаях с некоторыми популярными устаревшими программами, И, как вы, наверное, знаете, изменение такого рода вещей в унаследованных программах может быть довольно болезненным и сопряжено с рядом проблем, например, несовместимостью, которая может привести к тому, что разработчику придется переписывать исходный код. Таким образом, есть и тот факт, что distutils является частью стандартной библиотеки python, а setuptools - нет. Итак, если вы создаете программу на Python, в наше время используйте setuptools, однако имейте в виду, что без distutils setuptools никогда бы не существовало.
Ответ 2
тот факт, что setuptools не в стандартной библиотеке единственная причина
Это одна из причин. Следующее прямо из NumPy setup.py
:
if len(sys.argv) >= 2 and ('--help' in sys.argv[1:] or
sys.argv[1] in ('--help-commands', 'egg_info', '--version',
'clean')):
# Use setuptools for these commands (they don't work well or at all
# with distutils). For normal builds use distutils.
try:
from setuptools import setup
except ImportError:
from distutils.core import setup
Поэтому NumPy предпочитает setuptools
если он может его найти. Но тогда SciPy делал это до тех пор, пока в некоторых ситуациях не было исправлено предпочтение distutils
. Ссылаясь на журнал фиксации:
Setuptools sets mode +x on the test scripts, so that Nose refuses to run
them. Better not do that.
Конечно, слияние между setuptools
и distribute
должно решить все это в свое время, но многие пакеты все еще должны поддерживать установки Python 2.6.
Ответ 3
Есть несколько причин, по которым мы все еще говорим и используем distutils, хотя setuptools, без сомнения, лучший набор инструментов.
Во-первых, distutils доступен повсюду. Если вы хотите создать модуль для совместного использования с другими, и у вас нет каких-либо сложных требований, он гарантированно будет доступен на вашем рабочем компьютере. Это особенно важно, если вы должны поддерживать более старые версии python или если вы работаете в незнакомой среде.
Во-вторых, setuptools обеспечивает усовершенствования distutils. Поэтому он моделируется после набора инструментов distutils и берет оттуда всю структуру. Документация для setuptools предполагает, что читатель знаком с distutils и только документами, как он улучшает базовый набор инструментов. Вы можете думать, что distutils определяет диалект, а setuptools усиливает этот диалект.
Мой личный подход к новым проектам начинается с предположения, что я буду использовать distutils. Только по мере того, как проект растет, чтобы потребовать функцию setuptools, я делаю обновление. Setuptools - это замена для distutils, это однострочное изменение в моей setup.py.
Ответ 4
В основном это связано с разделением обязанностей.
setuptools
не входит в стандартную библиотеку Python, потому что он поддерживается третьей стороной, а не основной командой Python. Это означает, среди прочего:
- он не распространяется на базовый набор тестов и на него не ссылаются основные функции
- он сам не устанавливает основные стандарты для дополнительных модулей (их расположение, средства импорта, двоичный интерфейс C extensions и т.д.).
- он обновляется и выпускается независимо от выпусков Python.
Фактически, основная команда сузила область distutils, зарезервировав для себя "основные стандарты" и "минимальные необходимые компиляции" , оставив все вещи за пределами этого (расширенный формат компилятора/пакета/любая поддержка) третьим сторонам. Код, который ранее охватывал эти "расширенные части", был оставлен устаревшим для обратной совместимости.
От Распространение модулей Python - Документация на Python 2.7.12:
При постепенном прекращении прямого использования distutils
он все еще фундамент для существующей инфраструктуры упаковки и распределения, и он не только остается частью стандартной библиотеки, но и его имя живет другими способами (например, имя списка рассылки, используемого для координация разработки стандартов упаковки Python).
Пакеты для других ОС также, вероятно, будут предоставлять setuptools
и pip
отдельно - по вышеупомянутым причинам
- и потому, что они не нужны или даже вредны для ремонтопригодности - когда в системе уже есть менеджер пакетов.