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 отдельно - по вышеупомянутым причинам

  • и потому, что они не нужны или даже вредны для ремонтопригодности - когда в системе уже есть менеджер пакетов.