2009-11-05 1 views
18

Недавно я прочитал сообщение в блоге, в котором говорится, что хорошей практикой является разработка приложений Perl, так же, как вы разработали модуль CPAN. (Here it is - спасибо Дэвиду!) Одна из причин была в том, что вы могли просто запустить cpan . в каталоге проекта, чтобы установить все зависимости. Это звучит разумно, и мне также нравится «единый интерфейс», который вы получаете. Когда вы сталкиваетесь с таким приложением, вы знаете, что делает make-файл и т. Д. Каковы другие преимущества и недостатки этого подхода?Разрабатываете ли вы свои приложения Perl в качестве модулей CPAN?


Update: Спасибо за ответы. У меня есть еще один вопрос об установке зависимостей, я буду post it separately.

ответ

11

Вообще, да, я бы сказал, что это хорошая идея. Catalyst делает это проще, так как helper-скрипт catal.pl создаст базовую структуру для вашего веб-приложения, дополненную Makefile.PL и т. Д.

Это означает, что упаковка вашего приложения и его развертывание на сервере тривиально проста ,

Редактировать: Я думаю, что исходное сообщение в блоге, о котором вы думали, было Write your code like it's going on CPAN от Perlbuzz.

" Рассматривая код, мы никогда не собирались выпускать CPAN, как если бы мы были, мы выиграли поддержку всей инструментальной цепочки CPAN. Цепь, которая становится лучше с каждым днем. "

-4

Публикация вещей CPAN означает ответственность. вам нужно предоставить хороший документ, дальнейшую поддержку и другие. или иначе, не идите CPAN.

Благодаря

+7

На самом деле публикация кода для CPAN не была запрошена - «хорошая практика для разработки приложений Perl так же, как вы разрабатывали модуль CPAN», не означает, что вы фактически выпускаете ее в CPAN, только то, что вы разрабатываете в так же, как и для модуля, который вы планировали выпустить в CPAN. –

+4

Вы имеете в виду, что если вы не публикуете в CPAN, вам не нужно предоставлять хороший документ или поддерживать код? –

+0

Он просто горький, что кому-то из IRC не понравилось его использование пространства имен MooseX ::. – jrockway

6

Да, просто потому, что «модуль CPAN» устанавливает только очень либеральные практики. Я предпочитаю Module :: Install, я считаю, что большинству здравомыслящих людей тоже нужно. Для того, чтобы получить базовое распределение работает с модулем установки я просто использовать модуль стартер:

module-starter --mi --module "Foo::Bar" --author "Evan Carroll" --email "[email protected]"

Затем сразу же после того, как я редактирую стручок в Lib/Foo/Bar.pm: Я не люблю стручок в в середине моего кода. Я обычно перемещаю все это на дно и удаляю раздел FUNCTION и VERSION, потому что 99.9% моих модулей - OO с Moose, а Module :: Install будет читать его из $ Foo :: Bar :: VERSION.

Затем я запускаю git-init, редактирую файл .gitignore и добавляю 'MANIFEST', 'Meta.yml', 'Makefile.old', 'blib /', 'inc /' и какие-либо временные файлы редактор, который я создаю, может быть использован. (Если вы нажимаете на CPAN, вы захотите добавить .gitignore и .git/в MANIFEST.skip таким образом, чтобы они тоже не поднимались.) Тогда я git add ., и у меня есть мой модуль в git с загрузочной системой сборки/тестирования.

Затем я запускаю github, создаю репо, загружаю модуль и добавляю публичный репозиторий в Makefile.PL repository git://github.... и начинаем кодирование.

Даже если вы не нажимаете на CPAN, module-install обеспечивает неплохую основу для хорошего модуля.

Другие преимущества, вы можете запустить make dist и получить tarball и разместить его очень легко на частном сервере http, а затем просто скажите клиенту или серверу установить с cpanp http://host/path.Вы также получаете все преимущества Module::Install, он будет использовать dmake в окнах и загрузить dmake, если у вас его нет. Это довольно волшебно с кросс-платформенной добротой.

Нет никаких серьезных недостатков или даже незначительных примечательных примечаний.

+0

Вы пробовали Dist :: Zilla? – brunov