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

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

5 голосов
/ 19 марта 2010

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

Точные требования:

  • Код должен быть таким жев производстве и в бета-версии.

    Чтобы уточнить, чтобы продвигать любой код (библиотеку или сценарий) из бета-версии в производство, ЕДИНСТВЕННАЯ вещь, которая должна произойти, это буквально выдать команду cp из БЕТЫ в местоположение продукта - как имя файла, так и содержимое файла должны оставаться идентичными .

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

  • Пути кода должны быть одинаковыми для BETA и производства, за исключением базового каталога (/usr/code/ vs /usr/code/beta/)

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

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

Ответы [ 3 ]

2 голосов
/ 19 марта 2010

Я адресую это с помощью FindBin : 

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

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

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

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

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

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

ОБНОВЛЕНИЕ: Это не работает, если сами сценарии могут находиться в нескольких подкаталогах данного каталога, но работает иначе.

2 голосов
/ 19 марта 2010

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

  • Иметь библиотеку (назовем ее BetaOrProd.pm)

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

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

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

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

  1. Требование, чтобы каждый скрипт должен иметь "use BetaOrProd;" в качестве самого первого оператора use в каждом скрипте после прагмы "use strict;".

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

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

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

0 голосов
/ 19 марта 2010

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

...