Почему в проектах Python нет Makefile для автоматизации?

Question

Как давний программист на Python, мне интересно, не ускользал ли меня центральный аспект культуры Python: что мы делаем вместо Makefiles?

Большинство проектов ruby, которые я видел (нетолько рельсы) используйте Rake , вскоре после того как node.js стал популярным, появился cake .Во многих других (скомпилированных и не скомпилированных) языках существуют классические Make файлы.

Но в Python, похоже, никому не нужна такая инфраструктура.Я случайно выбрал проекты Python на GitHub, и у них не было никакой автоматизации, кроме установки, предоставляемой setup.py.

В чем причина этого?

Есть линечего автоматизировать?Большинство программистов предпочитают запускать проверки стиля, тесты и т. Д. Вручную?

Некоторые примеры:

• dependencies устанавливает virtualenv и устанавливает зависимости
• check вызывает pep8 и pylint commandlinetools.
• задача test зависит от dependencies, включает virtualenv, запускает selenium-server для интеграционных тестов и вызывает nosetest
• Задача coffeescript компилирует все сценарии кофе в минимизированный JavaScript
• Задача runserver зависит от dependencies и coffeescript
• Задача deploy зависит от check и test и развертывает проект.
• Задача docs вызывает sphinx с подходящими аргументами

Некоторые из них - только один или два ряда, но ИМХО,они складываются.Из-за Makefile мне не нужно их запоминать.

Чтобы уточнить: я не ищу Python-эквивалент для Rake.Я рад с асфальтоукладчиком.Я ищу причины.

Answer 1

На самом деле, автоматизация полезна и для разработчиков на Python!

Invoke, вероятно, является наиболее близким инструментом для автоматизации распространенных повторяющихся задач Python: https://github.com/pyinvoke/invoke

С помощью invoke вы можете создать файл tasks.py, подобный этому (заимствованный из документов invoke)

from invoke import run, task

@task
def clean(docs=False, bytecode=False, extra=''):
    patterns = ['build']
    if docs:
        patterns.append('docs/_build')
    if bytecode:
        patterns.append('**/*.pyc')
    if extra:
        patterns.append(extra)
    for pattern in patterns:
        run("rm -rf %s" % pattern)

@task
def build(docs=False):
    run("python setup.py build")
    if docs:
        run("sphinx-build docs docs/_build")

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

$ invoke clean
$ invoke build --docs

Другой вариант - просто использовать Makefile. Например, Makefile проекта Python может выглядеть так:

docs:
    $(MAKE) -C docs clean
    $(MAKE) -C docs html
    open docs/_build/html/index.html

release: clean
    python setup.py sdist upload

sdist: clean
    python setup.py sdist
    ls -l dist

Answer 2

Setuptools может автоматизировать многие вещи, а для вещей, которые не являются встроенными, легко расширяется.

• Для запуска юнит-тестов вы можете использовать команду setup.py test после добавления аргумента test_suite к вызову setup(). ( Документация )
• Зависимости (даже если они недоступны в PyPI) можно обработать, добавив аргумент install_requires / extras_require / dependency_links к вызову setup(). ( Документация )
• Для создания пакета .deb вы можете использовать модуль stdeb.
• Для всего остального вы можете добавить пользовательские команды setup.py .

Но я согласен с S.Lott, большинство задач, которые вы хотели бы автоматизировать (кроме обработки зависимостей, может быть, это единственное, что я считаю действительно полезным), это задачи, которые вы не запускаете каждый день, так что не будет любое реальное повышение производительности за счет их автоматизации.

Answer 3

В Python есть несколько вариантов автоматизации. Я не думаю, что существует культура против автоматизации, просто нет единственного доминирующего способа сделать это. Общий знаменатель - distutils .

Тот, который закрыт для вашего описания, buildout . В основном это используется в мире Zope / Plone.

Я сам использую следующие комбинации: Распространение , pip и Fabric . Я в основном занимаюсь разработкой с использованием Django, у которого есть manage.py для команд автоматизации.

Он также активно работает над Python 3.3

Answer 4

Любой приличный тестовый инструмент может запускать весь пакет одной командой, и ничто не мешает вам использовать rake, make или что-то еще, на самом деле.

Нет особых оснований изобретать новый способ ведения дел, когда существующие методы работают совершенно хорошо - зачем заново изобретать что-то только потому, что ВЫ его не изобретали? (NIH).

Answer 5

Исходный PEP, где он был поднят, можно найти здесь .Distutils стал стандартным методом распространения и установки модулей Python.

Почему?Просто так получается, что python - замечательный язык для установки модулей Python с помощью.

Answer 6

Утилита make - это инструмент оптимизации, который сокращает время, затрачиваемое на создание образа программного обеспечения. Сокращение времени достигается, когда все промежуточные материалы из предыдущей сборки все еще доступны, и во входные данные были внесены лишь небольшие изменения (такие как исходный код). В этой ситуации make может выполнять «инкрементную сборку»: перестраивать только подмножество промежуточных элементов, на которые влияет изменение входных данных.

Когда происходит полная сборка, все, что make эффективно делает, это выполняет набор шагов сценариев. Эти же самые шаги можно просто поместить в плоский сценарий. Параметр -n make фактически напечатает эти шаги, что делает это возможным.

Makefile - это не «автоматизация»; это «автоматизация с целью оптимизированной пошаговой перестройки». Все, что написано с помощью любого скриптового инструмента, является автоматизацией.

Итак, почему проект Python отказывается от таких инструментов, как make? Возможно, потому что проекты Python не борются с длительным временем сборки, которое они стремятся оптимизировать. Кроме того, компиляция файла .py в .pyc не имеет такой же сети зависимостей, как .c в .o.

Исходный файл C может #include сотни зависимых файлов; изменение одного символа в любом из этих файлов может означать, что исходный файл должен быть перекомпилирован. Правильно написанное Makefile определит, когда это так или нет.

Большой проект C или C ++ без системы инкрементной сборки будет означать, что разработчик должен ждать часов , пока исполняемый образ не появится для тестирования. Быстрые инкрементальные сборки необходимы.

В случае с Python, вероятно, все, о чем вам следует беспокоиться, это когда файл .py новее соответствующего ему .pyc, что можно обработать простым сценарием: переберите все файлы и перекомпилируйте что-нибудь новее чем его байт-код. Более того, компиляция необязательна в первую очередь!

Таким образом, причина, по которой проекты Python не используют make, заключается в том, что они нуждаются в оптимизации пошаговой перестройки, и для автоматизации используются другие инструменты; инструменты, более знакомые программистам Python, например, сам Python.

Answer 7

Разве нечего автоматизировать?

Не совсем.Все примеры, кроме двух, являются однострочными командами.

tl; dr Очень мало это действительно интересно или сложно.Похоже, что это очень мало помогает «автоматизации».

Из-за документации мне не нужно запоминать команды для этого.

Большинство программистов предпочитают запускать проверки стилей, тесты и т. Д. Вручную?

Да.

при создании документации задача docs вызывает sphinx с соответствующими аргументами

Это одна строка кода.Автоматизация не очень помогает.sphinx-build -b html source build/html.Это сценарий.Написано на Python.

Мы делаем это редко.Несколько раз в неделю.После «значительных» изменений.

работает stylechecks (Pylint, Pyflakes и pep8-cmdtool).check вызывает команды командной строки pep8 и pylint

Мы этого не делаем.Мы используем модульное тестирование вместо Pylint.Вы можете автоматизировать этот трехступенчатый процесс.

Но я могу видеть, как SCons или make могут помочь кому-то здесь.

tests

Там может быть место для "автоматизация "здесь.Это две строки: юнит-тесты не-Django (python test/main.py) и тесты Django.(manage.py test).Автоматизация может быть применена для запуска обеих линий.

Мы делаем это десятки раз в день.Мы никогда не знали, что нам нужна «автоматизация».

зависимостей устанавливает virtualenv и устанавливает зависимости

Сделано так редко, что простой список шагов - это все, что мы 'когда-либо нужно.Мы очень, очень тщательно отслеживаем наши зависимости, поэтому никаких сюрпризов не бывает.

Мы этого не делаем.

тестовое задание зависит от зависимостей, включает virtualenv, запускает selenium-server для интеграционных тестов и вызывает nosetest

start server & run nosetest как двухступенчатая «автоматизация» имеет некоторый смысл.Это избавляет вас от ввода двух команд оболочки для выполнения обоих шагов.

задача coffeescript компилирует все сценарии coffeescript в минимизированный javascript

Это очень редко для нас.Я полагаю, это хороший пример того, что нужно автоматизировать.Автоматизация однострочного сценария может быть полезна.

Я могу видеть, как SCons или make могут помочь кому-то здесь.

задача runserver зависит от зависимостей иcoffeescript

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

Задача развертывания зависит от проверки и тестирования и развертывает проект.

Это svn co и python setup.py install на сервере, за которыми следует множество пользовательских копий из области subversion в область /www клиента.Это сценарий.Написано на Python.

Это не обычные марки или SCons.У него есть только один актер (системный администратор) и один вариант использования.Мы никогда не будем смешивать развертывание с другими задачами разработки, контроля качества или тестирования.