Погружаясь в разработку на Python...

Последнее время промышляю написанием скриптов, которые автоматиризуют различные рутиные операции:
- правка файлов AssemblyInfo.cs с целью внесения build number, git branch name, git commit hash
- компиляция Visual Studio 2010 solution с проектами на C#/.NET 4.0
- анализ кода с помощью утилиты Gendarme
- подготовка deployment архивов, в которые складываем все бинарники за исключением XML-файлов с документационными комментариями, временных файлов, лог-файлов
- сбор всех тикетов Redmine для текущего билда и внесение соответсвующего комментария в каждый из этих тикетов

Планирую еще добавить запуск NUnit тестов в связке с PartCover, подготовку Test Code Coverage отчета в HTML-формате.

Сейчас Code Coverage метрики мы вообще не собираем - никак не дойдут руки добавить, а запуск NUnit тестов для нас делает TeamCity.

Хочу прийти к тому чтобы разработчик или QA имел возможность локально запустить билд скрипт, который бы выполнил всю ту же работу, которая происходит на CI-сервере TeamCity.


Какое-то время я размышял об инструменте, который можно использовать для этих целей и в итоге остановился на CPython.

Среди кандидатов еще рассматривались Cygwin + Bash, PowerShell, IronRuby + Rake, IronPython.

Cygwin + Bach кроссплатформенные, однако язык Bash за счет своей долгой истории развития выглядит достаточно несогласованным в плане синтаксиса. На нем не очень удобно писать императивный код и я не видел чтобы кто-то использовал там дебаггер.

PowerShell напротив, отличается очень хорошей синтаксической согласованностью. У этого языка отличная интеграция с платформой Windows и .NET, что для меня как .NET разработчика неоспоримое преимущество. К тому же мне удалось найти редактор скриптов с отладчиком. Но все таки мне хотелось иметь возможность писать императивный код средней сложности, который был бы кроссплатформенным.

IronRuby + Rake можно расценивать как готовую билд систему с хорошим императивным языком. Если бы у меня не было работы с язком Pyhton, то, возможно, я бы выбрал именно этот вариант.

Python думаю не нужен в особой рекламе. Достаточно сказать что я его выбрал :) Ну а если серьезно, язык я выбрал для решения поставленных задач из-за того что он довольно популярен, решает задачи общего назначения, кросплатформенный, используется для разработки как Desktop так и Web-решений. Так же его используют для нетривиальных задач системного администрирования, которые не может "вытянуть" Bash. Наверное переломным для меня моментом была находка библиотеки Paver, которая судя по всему делает все то же, что и библиотека Rake.

На первых этапах разработка велась с использованием IronPython + paver + Visual Studio 2010 + Python Tools for Visual Studio 2010 beta, позже на CPython 2.7 + paver + concurrent.futures + lxml + Eclipse + PyDev. Сейчас присматриваюсь к среде разработки JetBrains PyCharm, хотя использование коммерческого продукта для подобных задач кажется расточительным.

По состоянию на сегодняшний день build/deplyment скрипты представляют из себя сборную солянку следующих библиотек:
- paver, BSD
- concurrent.futures, BSD
- lxml, BSD
- py-restkit, BSD
- simplejson, MIT
- http-parser, MIT

Так же я обращал внимание на следующие библиотеки:
- GitPython, BSD, работает, но не понадобилась
- PyActiveResource, MIT, не подошла из-за функциональных ограничений
- python-rest-client, GPLv3, не пробовал из-за лицензионных ограничений

Полиглотное программирование в .NET это хорошо. История внедрения IronPython

Неплохая статья. Выгодно отличается трезвым взглядом человека-практика.

Признаюсь что читать все комментарии сил не нашел, но хотелось бы оставить одну галочку в Success Stories исключительно для статистики. :)

Уже несколько лет работаю на одном большом проекте в котором с самого начала присутствовал скриптинг.

Причем начиналось это все с написания скриптов общего назначения на NVelocity и это был сущий ад, поскольку Velocity ну никак не является скриптовым языком общего назначения.

Но это было время .NET 1.1, IronPython'а тогда еще не было, а нам нужна была возможность написания скриптов, которые бы вызывались во время отработки различных фабричных методов.


В какой-то момент мы нашли проект IronPython и начиная с версии 1.0 RC я был человеком, который "двигал" этот язык и передавал опыт работы другим командам внутри нашего проекта.

Все это происходило медленно, но верно. По ходу дела я переезжал с одного релиза на другой, решая разного рода проблемы взаимодействия C# и IronPython при хостинге DLR внутри C# приложения.


Вначале были переписаны скрипты с NVelocity на IronPython практически один-в-один. Разве что я старался скрипты представлять в более организованном, процедурном виде ну и использовать простейшие возможности языка.

Следующим этапом был постепенный перевод всех скриптов на более высокоуровневую объектную модель. Тут пришлось пройтись по некоторым не очевидным граблям, которые выплывали во время наследования абстрактных классов C# в типах, которые я реализовывал на языке Python.

В конечном счете теперь у нас на проекте появляется все больше и больше скриптов на IronPython, которые постепенно становятся все более "умными".

При этом, скажу что мы, как суровые челябинские разработчики, пишем без IntelliSense и без отладчика. Спасает то, что я разобрался как можно вытащить script stack trace. :)



В конечном счете я для себя сделал такой вывод:

Многоязыковость платформы .NET это однозначно хорошо, так как позволяет в определенных ситуациях находить отличные решения. И мне кажется что эта самая многоязыковость или даже "распыленность" Microsoft по C#/F#/VB.NET/IronPython/IronRuby вряд ли нанесет существенный вред платформе в целом и языку C# в частности.

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

IronPython. Ссылки.

Начинаем работать с IronPython.
http://blogs.gotdotnet.ru/personal/AlexanderByndyu/PermaLink.aspx?guid=71d5dcff-7833-4242-ac06-5388ad993acf

Entry point для того чтобы начать работать с IronPython в Visual Studio 2008.


Блог автора языка IronPython:
http://blogs.msdn.com/haibo_luo/default.aspx


IronPython: Grab the .NET Type
http://blogs.msdn.com/haibo_luo/archive/2007/09/25/5130087.aspx

Можно сказать entry point по IronPython/.NET interop. Очень мало, но наглядно :)


IronPython: Keyword Argument to Set .NET Property/Field
http://blogs.msdn.com/haibo_luo/archive/2007/10/02/5246577.aspx

Если кто-нибудь любит свеженькие конструкции C# вроде Object Initializer, то стоит просмотреть этот пост.


IronPython: Passing Arguments for a Call
http://blogs.msdn.com/haibo_luo/archive/2007/10/01/5230964.aspx

Примеры использования разных способов передачи параметров в функцию - позиционные параметры, параметры со значением по-умолчанию, опциональные параметры, передача параметра по имени.


IronPython: Provide (or not) Argument for by-ref Parameter
http://blogs.msdn.com/haibo_luo/archive/2007/10/04/5284947.aspx

Вызов методов с ref-параметрами.


IronPython Cookbook
http://www.ironpython.info/index.php/Main_Page

Собрание материалов по IronPython.


SimplePrograms
http://wiki.python.org/moin/SimplePrograms

Своеобразные подсказки для тех, кто не хочет держать все время языковые конструкции в голове ;)


DLR Hosting and related stuff...
http://blogs.msdn.com/seshadripv/default.aspx

Релизная версия IronPython 2.0 работает поверх Dynamic Language Runtime. Если вам (не дай бог :) ) придется интегрировать хостинг Python-скриптов с вашим .NET-приложением, то тут можно почерпнуть максимум возможной информации.

Динамические языки в .NET проектах не за горами

Думаю что многие из .NET разработчиков уже неоднократно слышали о IronPython.

Да, действительно, поддержка настоящего скриптового языка была бы для такой серьезной платформы как .NET очень кстати.

IronPython начинал разрабатываться вначале независимым разработчиком, который в последствии перешел под крыло Microsoft.

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

Скажу что занятие это не то чтобы совсем уж тяжелое, но все-таки требует некоторой выдержки от разработчика.

Около полугода назад я ознакомился с IronPython Studio, средой разработки на языке IronPyton, которая была выполнена на базе Visual Studio 2008 Shell (isolated mode). Если проще, то это отдельная среда, как две капли воды похожая на Visual Studio 2008, однако исключительно для этого языка.

Сегодня я узнал о существовании IronPython Studio на базе Integrated Shell, что дает возможность сопровождать проекты на IronPython в одном решении вместе с проектами на других языках. А это уже совсем другая история... Очень надеюсь, что я не ошибаюсь на этот счет :)

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