Почему вы не используете модули CPAN?

Ответ 1

У вас может быть механизм сценариев Perl, встроенный в хост-приложение (например, веб-сервер или любое сложное приложение, требующее сценариев), и у вас есть множество ограничений во встроенном контексте, например, невозможность загрузки файлов.

Ответ 2

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

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

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

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

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

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

Вы не избегаете этих причин с помощью glib-ответов об использовании другой службы, установке в локальном каталоге и т.д. Вы не можете применять аргументы счетчика к каждой ситуации и настройке. Любой, кто говорит вам об этом, например, топ-пост в Top Seven (Плохие) причины не использовать модули, с которыми Леон ссылается, на самом деле не думает о любой ситуации, и есть много продуманных аргументов против контрагентов.

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

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

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

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

• Процесс установки слишком сложный. Четыре шага и сотни подсказок, возможно, были в порядке десять лет назад, когда было меньше пакетов и меньше зависимостей, но теперь это просто дрянной. Почему я не могу просто набрать что-то вроде "cpan-install Moose" в моей оболочке и сделать это? Это особенно странно, учитывая, что продвинутые пользователи часто утверждают, что переносимость - это добродетель, ссылаясь на такие вещи, как пакеты и PAR, которых я до сих пор не получаю. И почему установка локально еще сложнее, когда так много людей, похоже, хотят это сделать?

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

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

Итак, вы идете. Извинения за напыщенность.

Ответ 5

Установка модулей Perl на локальном уровне является довольно сложной задачей. Здесь мой процесс:

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

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

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

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

В противном случае вы можете запускать CPAN обычно: "perl -MCPAN -e shell" или просто "cpan". Вам будет предложено настроить. В разделе "Параметры для команды" perl Makefile.PL "?" Введите: "PREFIX=~ LIB=~/lib/perl5".

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

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

Ответ 6

Если вещи "пугают системных администраторов" достаточно, они не хотят, чтобы вы положили их на машину, независимо от того, где вы думаете, что вы их поместите. У магазинов есть стандарты по какой-то причине.

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

Когда вы выходите в реальный мир, где скрипты Perl могут работать вместе с 40-летним установленным, crusty, COBOL, вы можете понять, насколько еще легче управлять менеджерами COBOL, чем с "скриптами" в зависимости от в значительной степени на горячих любителей, однако умных.

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

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

(ответ, используйте PAR или PAR:: Packer)

Я предлагал ему PAR один раз, но это было совсем не практично. Ни одна из машин не является достаточно похожей на PAR, чтобы действительно быть полезной в общем случае. Его варианты заключались в следующем: не используйте модули или не поддерживайте 1300 двоичных файлов PAR. PAR довольно сложно нормально работать, даже когда вы определенно знаете целевую форму, поэтому он решил не использовать модули.

Ответ 10

Целевой хост имеет неудобную операционную систему, которая плохо поддерживается модулями CPAN (отчасти из-за отсутствия CPAN Testers).

Такими примерами являются AIX и HP-UX. У них есть старый perl, ни компилятор C, ни старый/сломанный, а старый/сломанные библиотеки, поэтому слишком много модулей XS не могут быть установлены из коробки. Для их исправления требуется время (особенно, когда автор CPAN не отвечает в течение нескольких месяцев), и попытки обхода XS-модулей на практике невозможны (ну, если вы действительно хотите так поступать, вы будете слишком часто исправлять чистые модули perl которые полагаются на модули XS).

Ответ 11

Это ответ с позитивным подходом, то есть он говорит, как вы можете исправить ограничения, препятствующие использованию модулей CPAN: Да, даже вы можете использовать CPAN.