Почему Вы не используете модули CPAN? [закрытый]

Существует несколько причин, что я иногда рекомендую людям не использовать определенные модули CPAN. Не все CPAN являются высококачественным кодом и там варьируются уровни обслуживания для различных дистрибутивов. Все должны рассмотреть, сколько работы они должны сделать для использования конкретного модуля CPAN и что тот модуль сохраняет их (т.е. общая стоимость владения). Используя какой-то конкретный модуль CPAN не всегда преимущество. Я не говорю, что люди не должны использовать ни один из CPAN, но они должны рассмотреть то, в чем они действительно нуждаются от него.

1. Внешняя зависимость от модуля позволяет кому-то еще повреждать Ваше приложение. Набор инструментальных средств CPAN только когда-либо заботится о последней версии модуля и может обновить Вашу установку, когда это видит, что у Вас есть более ранняя версия. Я видел, что много приложений повреждаются, когда базовые внешние зависимости представляют новые ошибки, удержанные от использования необходимые функции, и так далее. Это - одна из причин, я разрабатывал свои инструменты для компаний для хостинга их собственных репозиториев CPAN, таким образом, они могут управлять этим. Существуют другие способы смягчить, это, но не многие люди достаточно сложно, чтобы иметь хороший процесс для него.

2. Вы работаете в среде, где весь код должен быть утвержден. Это походит на глупое требование большому количеству людей, но у людей управления рисками есть задание, чтобы сделать также. Иногда то соответствие получает мандат согласно различным законам, стандартам ухода, и так далее. Если модуль действительно не собирается сэкономить много времени и энергии, преимущество не может стоить усилия пройти тот процесс. Действительно, сколько из Вас когда-нибудь серьезно осматривает код, который Вы получаете от CPAN? Там могло быть что-либо.

3. Некоторые модули CPAN реализуют тривиально кодированную функциональность. Используя модуль просто, потому что это находится на CPAN и Вы не хотите писать, что эти три строки кода сами немного глупы. Можно говорить о повторном использовании кода все, что Вы любите, но в конечном счете это - доведение до абсурда.

4. Установка некоторых модулей может быть довольно хитрой, хрупкой, и непредсказуемой, и иногда это происходит из-за длинного списка зависимостей, чтобы просто создать и протестировать модуль даже при том, что Вам не нужны те зависимости для фактического использования модуля. Требуется большая работа для обработки этих случаев в автоматизированных тестовых средах.

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

Вы не выходите из этих причин с бойкими ответами об использовании другого сервиса, установке в локальном каталоге, и так далее. Вы не можете применить свои встречные аргументы каждой ситуации и установке. Любой говорящий Вам иначе, такие как лучшая публикация в Лучших Семи (Плохих) Причинах Не Использовать Модули, что ссылки Leon на, действительно не думает ни о чьей ситуации, и существует много вдумчивых противовстречных аргументов.

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

Можно найти это эссе (и его комментарии) интересный.

Я рад, что Вы спросили.

Я думал о задавании вопроса как, "Почему CPAN должен высосать так много?" но решенный не стоило жертвовать моей репутацией, когда я (думают I) уже знаю ответ. И так как этот вопрос отмечен "субъективный", я поблагодарю Вас за то, что не модерировался я вниз для предоставления моего персонального взятия по этой проблеме, даже если Вы будете думать, что я ошибаюсь или глуп.

Сначала некоторый фон: Я сделал довольно большое кодирование Perl в середине девяностых и наслаждался им, но в конечном счете пришел к заключению, что язык испытал недостаток в большом количестве функций, которые были необходимы для "реального" объектно-ориентированного программирования. Я стал разработчиком C++ в течение нескольких лет и теперь являюсь теперь очень техническим менеджером проектов. Я все еще использую Perl для сценариев и уплотнения данных и других остатков, и недавно начал использовать сценарии Perl для тестирования веб-сервисов, которые разработали наши кодеры.

Так или иначе я пришел к переполнению стека для управления проектами, но остался для Perl. Я рад видеть, что язык вырос и имеет все виды фантастического модуля как Американский лось и MVC и обрабатывает по шаблону и так далее и хотел бы использовать их..., и я буду. Но это занимает время, и у меня только есть несколько часов время от времени для работы с ним. Почему это не легко?

Но отвечать на вопрос...

1. Сначала очевидный ответ: для большинства программ Perl не нужны модули CPAN.

2. Существует больше чем один способ сделать это. Мне не нужны модули, чтобы сделать много вещей, что я использовал бы модули для того, если бы было легко сделать так. Например, я анализировал XML-документы с разделением () и регулярные выражения. Я знаю, что это неправильно (но первый шаг к восстановлению признает, что у Вас есть проблема). Но я могу скопировать и вставить код, чтобы сделать это через несколько секунд, или я мог уйти и попытаться заставить cpan работать в течение другого месяца или около этого.

3. Теперь позволяет, становятся немного более спорными. CPAN является хрупким. Ранее в этом году я пытался использовать cpan для установки Американского лося, потому что я считал большие вещи об этом и стремился сделать надлежащее программирование OO в Perl и для него, чтобы не быть твердым/ужасным. Таким образом, я следовал инструкциям по установке и нажал 'Y' сотни времени (это казалось) прежде чем быть чернившим со страницами и страницами предупреждений компилятора на заключительном шаге. Что, черт возьми, я делаю теперь? Мое основное dev поле имеет своего рода полуповрежденный модуль Американского лося, просто ожидая (я уверен) укусить меня в заднице, когда я меньше всего ожидаю это. Это было приблизительно два месяца назад, и я не вернулся. Я размышляю, что много Perl/CPAN имеет зависимости от других языков программирования, и это делает это более хрупким (в противоположность языкам, библиотеки которых кодируются на том же языке). Я далее размышляю, что события как это отпугивают потенциальных пользователей.

4. Документация для новичков CPAN плоха. Где авторитетная документация CPAN так или иначе? Где введение и учебные руководства для новичков? И как я, как предполагалось, знал это? Я читал документацию CPAN относительно и прочь в течение нескольких месяцев, и начинаю выяснять, где вещи. (Я вижу, что почти все отдельные модули Perl на CPAN красиво документируются внутренне, но мне потребовалось долгое время для нахождения той документации.)

5. Процесс установки слишком труден. Четыре шага и сотни подсказок, возможно, были хорошо десять лет назад, когда было меньше пакетов и меньше зависимостей, но теперь это просто дрянно. Почему я не могу только ввести что-то как 'Американский лось cpan-установки' в моей оболочке и иметь его быть сделанным? Это особенно странно, учитывая, что опытные пользователи часто утверждают, что мобильность является достоинством, цитируя вещи как пакеты и ПАРИТЕТ, который я все еще не получаю. И почему устанавливает локально еще тяжелее, когда столько людей, кажется, хочет сделать это?

6. Там досаждают проблемам, как то, должен ли я установить модули CPAN с cpan или с системой управления пакета, где совет непоследователен. В более общем плане: существует больше чем один способ сделать это. И когда Вы начинаете делать усовершенствованный Perl, необходимо ли принять решения относительно того, как установить модули и какие модули использовать и где Вы запускаете? Помните, что Вы - новичок, и документация отчасти фрагментируется, и кривая обучения крута. Мое решение состояло в том, чтобы попытаться работать вокруг этого, не используя cpan, в то время как я читал немного больше.

7. Наконец, усовершенствованный Perl имеет очень крутую кривую обучения. Усовершенствованные пользователи Perl, по-видимому, не помнят это и не видят его. IMO там является миром различия между использованием Perl, поскольку это было первоначально задумано - как практическое извлечение и создание отчетов о языке с мощными регулярными выражениями - и использование его как современная платформа разработки с OO и шаблоны и MVC и все виды других положительных героев. Я должен все же найти нежный, возрастающий путь от случайного использования Perl до усовершенствованного использования Perl.

Таким образом, там Вы идете. Извинения за напыщенную речь.

Установка модулей Perl локально является небольшим оспариванием. Вот мой процесс:

Установка локализованная пользователями конфигурация CPAN:

mkdir -p ~/.cpan/CPAN
touch ~/.cpan/CPAN/MyConfig.pm

Если CPAN был ранее установкой для по всему сайту администратора (значение, Вы находитесь на своем собственном поле и уже разожженном и настроенном CPAN), можно измениться на локальный для пользователя:"perl -MCPAN -e mkmyconfig". Затем редактирование"~/.cpan/CPAN/MyConfig.pm":

'makepl_arg' => q[LIB=/home/your_name/perllib],

Иначе можно обычно запускать CPAN:"perl -MCPAN -e shell"или просто"cpan". Вам предложат конфигурацию. В "Параметрах для 'Make-файла жемчуга. МН' команда?", Войдите:"PREFIX=~ LIB=~/lib/perl5".

Для ссылки на локально установленные модули в сценариях Perl можно сделать use lib прагма, но я думаю, что это - раздражающая зависимость, когда у Вас есть многочисленные сценарии жемчуга и модули для обновления в приложении. Это - больше обходного решения.

Вместо этого я могу установить var среды PERL5LIB к пути, где модуль был установлен локально, как"$HOME/lib/perl5". Установить PERL5LIB для среды CGI выясните, как установить переменные среды в конфигурации сервера. В Apache я могу выполнить в этом httpd.conf или в .htaccess использование mod_env. (спасибо, brian d foy)

Если вещи "пугают системных администраторов" достаточно, они не хотят, чтобы Вы поместили их на машину, независимо от того, где это - Вы, думают, что Вы поместите их. Магазины имеют стандарты по причине.

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

Когда Вы выходите в реальный мир, куда сценарии Perl могут работать вместе с 40 годами, установленными, твердыми, КОБОЛ, можно понять, сколько еще непринужденно менеджеры с выполнением КОБОЛа, чем они со "сценариями", зависящими в большой степени от горячих людей, увлеченных своим хобби, однако умных.

Тем не менее мой текущий магазин несколько доволен Perl для некритических сценариев и отчетов, и установит случайный модуль CPAN, но процесс подтверждения строг, тестирование песочницы является долгим (и дорогим!), но позволяет. Я могу только предположить, что они могли утвердить один или два новых модуля, не 50 + новые модули, из-за того, какому количеству новых ситуаций это выставит их. Таким образом, модули, созданные ", Позволяют нам просто использовать CPAN" толпа, в значительной степени отсутствуют, если зависимость говорит "Не рекомендуемый для производственного кода" или "экспериментальный".

Вот одна допустимая причина, о которой я могу думать: Вы хотите выяснить, как сделать это сами. Который прекрасен, пока Вы понимаете, что продуктивная среда не для Ваших собственных персональных экспериментов.

Можно было бы сказать "хорошо взгляд на то, как модуль CPAN делает это", но чтение чужой реализации является плохой заменой для того, чтобы сделать его самостоятельно. И честно много реализаций CPAN является довольно ужасающим. Это могло бы осуждать на качестве кода CPAN, но также история успеха на, как хорошо инкапсулированный и протестировал модуль CPAN, - то, что по большей части Вы не замечаете.

Относительно всех ответов, которые являются вариациями на "оболочку CPAN, твердо настроить", я соглашаюсь. Однако это - O (1) проблема. Вы решаете его однажды, и затем Вы получаете легкий доступ к CPAN для остальной части Вашей жизни.

Некоторые модули основаны на библиотеках с открытым исходным кодом и не компилируются и не работают хорошо во всех психических средах, которые вы используете. иметь. Рассмотрим, например, необходимость работы в NCR, HP, SUN, Linux и AIX.

целевая машина не обязательно имеет необходимый модуль

Это может быть допустимо в некоторых средах. Один из моих друзей работает в огромном мега конгломерате, охватывающем страны и континенты. Часто, он использует жемчуг, чтобы заставить ленточные накопители сделать вещи во всем мире. Сценарии должны быть развернуты на буквально тысячах машин, и модули установки действительно грандиозное предприятие - обычно вовлечение комитета и нескольких системных администраторов в каждом физическом местоположении. Он склонен избегать их любой ценой, и я не могу сказать, что обвиняю его.

Существует ли решение для этого? Я действительно не думаю, что существует.

(Это выше - вырезанный и вставленный от моего ответа до действительно подобного вопроса на permonks.)

http://perlmonks.org/?node_id=750387

(ответ, используйте ПАРИТЕТ или ПАРИТЕТ:: Упаковщик)

Я действительно предлагал ПАРИТЕТ ему однажды, но это не было практично вообще. Ни одна из машин не достаточно подобна, чтобы ПАРИТЕТ действительно был полезен в общем случае. Его опции были: не используйте модули или поддерживайте 1 300 двоичных файлов ПАРИТЕТА. ПАРИТЕТ Довольно труден получить работу действительно хорошо, даже когда Вы определенно знаете целевую patform, таким образом, он выбрал не использовать модули.