Как использовать бета-модули Perl из бета-скриптов Perl?

Question

Если мой код Perl имеет место производство кода и местоположение «бета» кода (например, производство Perl код нам в /usr/code/scripts, BETA код Perl в /usr/code/beta/scripts, библиотеки производства Perl в /usr/code/lib/perl и бета-версии этих библиотек в /usr/code/beta/lib/perl, есть простой способ для меня, чтобы достичь такой установки

точных требований являются:.

• код должен быть одинаковым в производстве и месте БЕТЫ

  Чтобы прояснить, для продвижения любого кода (библиотеки или скрипта) от BETA до производства, ТОЛЬКО вещь, которая должна произойти, буквально выдает команду cp из BETA на место prod - и имя файла И содержимое файла должно оставаться идентичным.

• BETA версия скриптов должна вызывать другие сценарии бета- и бета-версию библиотеку (если есть) или производственные библиотеки (если БЕТА библиотека не существует)

• Пути кода должен быть одинаковым между БЕТА и производством с исключение из базового каталога (/usr/code/ против /usr/code/beta/)

• сценарии должны быть все под одной и той же базовой директории , но они могут быть в его подкаталогах на произвольном уровне глубины (это исключает классический use lib "$FindBin::Bin/../lib" решение из раздела 31.13. использовать Lib из «Программирование на Perl»)

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

Answer 1

Наше собственное решение было следующим:

• Есть библиотека (назовем его BetaOrProd.pm)

  • библиотека должна быть включена с помощью "use BetaOrProd;" в каждый сценарий
  • Библиотека ДОЛЖНА быть самой первой операцией use в каждом скрипте после «use strict;» pragma (и «использовать предупреждения», если мы используем это). В том числе перед любыми блоками BEGIN.
  • Библиотека имеет BEGIN блок, который содержит большую часть логики
  • Это BEGIN блока в чеках библиотеки пути к директории программы (на основе офф $ 0 с абсолютным путем прикладным)
  • Если путь к директории начинается с /usr/code/beta, программа считается работать в БЕТА месте, еще в производстве
  • в любом случае, /usr/local/lib/perl ООН является смещенной в начало списка @INC
  • Если БЕТА место, /usr/code/beta/lib/perl ООН является смещенной к началу @INC список после этого.
  • Если BETA-местоположение, специальная переменная $ isBETA (доступная методом доступа, экспортированной из BetaOrProd.pm), установлена ​​в «BETA».

• Anytime скрипт/библиотека должна вызвать другой сценарий, путь к вызываемому сценарию рассчитывается на основе указанного сбруя до $ isBETA переменного, экспортируемых из BetaOrProd.pm

• В любое время Perl потребности библиотеки в требуются или используются, никакой специальной логики не требуется - @INC, измененный BetaOrProd.pm, заботится о том, откуда следует импортировать модули. Если модуль присутствует в местоположении BETA, то библиотека из местоположения BETA будет использоваться сценарием BETA, иначе библиотека из местоположения prod.

Основные недостатки этого подхода являются:

1. Требования, что каждого сценарий должен иметь «use BetaOrProd;» в качестве самого первого use заявления в любом сценарии после «use strict;» Прагмы.

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

2. Невозможно провести тест BETA BetaOrProd.pm через /usr/code/beta/lib/perl. D'эм.

   смягчается очень тщательным блоком и тестированием интеграции библиотеки

Answer 2

Я должен был использовать подобную конфигурацию. Однако модуль был назван в честь имени проекта и мог выполнять некоторые другие обязанности: загрузка некоторых переменных конфигурации для конкретной среды (например, размещение данных, учетные данные для баз данных dev/prod), обработка некоторых аргументов командной строки и установка некоторые другие переменные, которые были полезны для большинства сценариев в проекте (текущая дата в формате YYYYMMDD, был ли фондовый рынок в настоящее время открыт, и т.д.)

Answer 3

обращаюсь это с FindBin:

use FindBin; 
use lib "$FindBin::Bin/../lib"; 

Или, если активен режим обжатия:

use FindBin; 
use lib ("$FindBin::Bin/../lib" =~ m[^(/.*)])[0]; 

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

Я поддерживаю полные копии всех модулей проекта в каждом образце проекта проекта, но похоже, что вы этого не делаете и вместо этого полагаетесь на бета-версию, возвращающуюся к модулям живой копии; a use lib /path/to/live/bin до того, как use lib s выше будет обрабатывать это, или вы можете просто связать /path/to/live/bin в один из каталогов на @INC, чтобы он всегда был доступен сразу.

Если в реальном времени и бета-версии будут запускаться из разных учетных записей, local::lib также может стоить посмотреть, но на самом деле это не похоже на то, для чего предназначено.

UPDATE: Это не работает, если сами скрипты могут жить в нескольких подкаталогах данного каталога, но работает иначе.