Действительно ли Python является правильным молотком для этого гвоздя? (создайте сценарий) [закрытый]

Пакетные файлы не являются злыми - на самом деле они прошли довольно долгий путь от мертвых дней на command.com. Командный язык в наше время может быть довольно выразительным, вам просто нужно приложить немало усилий, чтобы выучить его.

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

Смутное чувство зла не было бы причиной для меня тратить усилия на «исправление» того, что не сломано. И это будет напрасной тратой усилий, если нет явного преимущества для изменения («меньшее зло» - это не то, что я считаю очевидным преимуществом).

Когда вы ' упоминая Python и SCons, я бы сказал, пойти на SCons. Это Python в конце концов. И да, любой из вышеперечисленных будет лучшим выбором, чем сценарии ручной сборки.

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

Я бы предложил использовать NAnt для вашего скрипта сборки вместо python. Мои причины для этого:

• У него уже определены задачи, все, что вам нужно сделать, это написать XML и указать его в нужных местах. Если вы работаете с людьми, которые не знают Python, XML может быть немного менее страшным, чем изучение нового языка.
• NAnt предназначен для работы в среде Windows .Net, поэтому он уже может выполнять задачи MSBuild и NUnit.
• Если вы уже пишете на C #, если вам нужно расширить NAnt для выполнения новых задач, вы не добавляете другой язык в смесь вашего проекта.
• Вы можете подключиться к Cruise Control .Net (для непрерывных сборок). Что, я думаю, является основной причиной, по которой вы бы использовали NAnt.

Почему вы должны использовать Python? Если ваш скрипт сборки не сломан, не исправляйте его. Если у вас возникли проблемы с его обновлением, чтобы иметь дело с новыми добавками в проект, вы можете захотеть переписать его. Я бы не стал использовать Python, хотя такие инструменты, как NANT или MSBuild, делают эту работу. Я не вижу смысла в использовании общего языка программирования purpis для того, чтобы делать то, для чего инструменты уже написаны, если у вас нет множества непонятных требований, с которыми существующие инструменты не могут справиться. Во-вторых, что произойдет, если вас сбьет автобус или вы выиграете в лотерею? Если вы полны решимости написать все, я бы использовал powershell или какую-то другую специальную технологию Microsoft, поскольку вы уже подключены к Microsoft. Если вы уйдете, хватит ли программистов на Python для поддержки сценариев сборки?

Я настоятельно рекомендую взглянуть на waf . Это то, что вы хотите: «основанная на Python инфраструктура для настройки, компиляции и установки приложений»

Лично я бы использовал сценарии в качестве крайней меры, учитывая, что

• Немного поработав, вы можете заставить MSBuild сделать все это за вас, дополнив его дополнительными компонентами
• . являются сторонними эквивалентами MSBuild, такими как NANT , которые могут делать то же самое
• Существуют целые инструменты, такие как FinalBuilder , которые также делают то же самое, и их легче конфигурировать и расширять

Однако, если бы мне пришлось пойти по сценарию сценария, я бы использовал Powershell по нескольким причинам:

• Полный доступ к файловой системе
• Вы можете легко получить доступ к объектам .NET
• Вы можете легко получить доступ к объектам COM

Вы можете создавать собственные make-файлы для инструмента Microsoft nmake, который вы уже установили. Использование такого инструмента (SCons, Maven и т. Д. Попадают в одну категорию) дает вам гораздо больше, чем обычные сценарии.

Основное преимущество заключается в том, что отслеживаются зависимости между файлами, а также временные метки изменений. Например, вы можете сделать свой .zip-файл зависимым от некоторых других файлов, поэтому .zip будет перепакован, только если некоторые из этих файлов изменились за это время. Так же, как с исходным кодом и его скомпилированной формой.

Python очень переносим. SCons испытан в полевых условиях и надежен. Учитывая то, что вы знаете (из того, что вы объяснили), зачем даже задавать вопрос?

Если вы поддерживаете что-то, речь идет не только о том, чтобы его собрать, но и об объяснении пользователю, почему оно НЕ МОЖЕТ строить, что спасает вас. тонна очень разочаровывающих вопросов, помогая пользователям помочь самим себе.

Я не могу представить себе современную производственную операционную систему, в которой отсутствует Python, если только вы не попадаете на встраиваемую / исследовательскую арену.

Итак, я отвечаю сказать, что вы ответили на свой вопрос:)

Это зависит от того, какую технологию использует ваше программное обеспечение. Если вы создаете программы на C ++, я бы, вероятно, сказал, что вы можете использовать scons без вопросов (если у вас нет странных требований, которым scons не может соответствовать). С другой стороны, рассмотрим инструкции по сборке C #: CSharpBuilder .

Я хотел бы знать (например), что дает мне SCons над обычным скриптом Python.

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

Но проблема в том, что пакетные файлы являются злыми.

Наконец, пакетные файлы зло, если они используются для проекта, с которым они не подходят.

Он выполняет такие действия, как запуск MSBuild, копирование файлов, создание ZIP-файла, выполнение некоторых тестов, включая номер версии подрывной версии и т. Д.

MSBuild и PowerShell могут легко сделать все это с помощью достаточно чистый сжатый код. Тогда вы будете придерживаться исключительно продуктов M $, которые, как правило, нравятся менеджерам. В противном случае я бы посоветовал вам изучить Rake, хотя бы из-за его большого сообщества. У него хороший синтаксис и поддержка железных рубинов (irake).

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

Посетите http://msbuildtasks.tigris.org/ , чтобы найти хорошие дополнения к MSBuild