Как установить специализированные среды для разных приложений Perl?

Есть ли что-то эквивалентное или близкое с точки зрения функциональности для Python virtualenv, но для Perl?

Я сделал некоторую разработку на Python, и возможность наличия несистемных версий модулей, установленных в отдельной среде без каких-либо беспорядков, является огромным преимуществом. Теперь мне нужно работать над новым проектом в Perl, и я ищу что-то вроде virtualenv, но для Perl. Можете ли вы предложить любой эквивалент Perl или замену для python virtualenv?

Я пытаюсь настроить X различных наборов не-системных пакетов Perl для Y различных приложений, которые будут развернуты. Хуже того, для этих приложений могут потребоваться разные версии одного и того же пакета, поэтому каждый из них может потребоваться установить в отдельную среду модулей/библиотек. Вы можете сделать это вручную для X < Y < 3. Но вы не должны делать это вручную для 10 > Y > X.

Идеально, что я ищу, должно работать следующим образом:

perl virtualenv.pl my_environment
. my_environment/bin/activate
wget http://.../foo-0.1.tar.gz
tar -xzf foo-0.1.tar.gz ; cd foo-0.1
perl Makefile.pl
make install # <-- package foo-0.1 gets installed inside my_environment
perl -MCPAN -e 'install Bar' # <-- now package Bar with all its deps gets installed inside my_environment

Ответ 1

Есть инструмент под названием local::lib, который завершает всю работу для вас, как virtualenv. Он будет:

Настройте @INC в том процессе, в котором он использовался.
Установите PERL5LIB и другие подобные вещи для дочерних процессов.
Установите правильные переменные, чтобы убедить CPAN, MakeMaker, Module::Build и т.д. для установки библиотек и сохранения конфигурации в локальном каталоге.
Установите PATH, чтобы можно было установить установленные двоичные файлы.
Перепечатывайте переменные окружения в stdout при использовании из командной строки, чтобы вы могли поместить eval $(perl -Mlocal::lib) в вашем .profile, а затем в основном забыть об этом.

Ответ 2

Во время исследования я обнаружил эту и некоторые другие страницы (этот слишком старый и пропускает новые технологии, этот пост reddit является небольшим неправильным направлением).

Проблема с perlbrew и plenv заключается в том, что они, похоже, заменяют pyenv, а не virtualenv. Как отмечено здесь pyenv предназначен для управления версиями python, virtualenv предназначен для управления версиями каждого модуля. Итак, да, в некотором роде похож на local:: lib, но с лучшим удобством использования.

Я еще не видел правильного ответа на этот вопрос, но из того, что я прочитал, похоже, лучшее решение - это что-то вроде:

Управление версиями Perl: plenv/perlbrew (с большинством людей благоприятствования более современным bash основанным на perl основе perlbrew из того, что я вижу)
Управление версиями модулей: Carton
Установка модуля: cpan (ну, cpanminus в любом случае, ymmv)

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

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

Ответ 3

Программы могут изменять, какие каталоги они проверяют для библиотек uwith use lib. Этот каталог lib может относиться к текущему каталогу. Библиотеки из этих каталогов будут использоваться перед системными библиотеками, поскольку они помещаются в начало массива @INC.

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

Ответ 4

Я не уверен, что это то же самое, что и те virtualenv, о которых вы говорите, но посмотрите специальную переменную @INC в man-странице perlvar.

Ответ 5

Я использовал schroot для этой цели. Это немного тяжелее, чем virtualenv, но вы можете быть уверены, что ничто не просачивается в это не должно.

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

Я думаю, что это может быть debian/ubuntu только.

После настройки schroot ваш script выше будет выглядеть как

schroot -c my_perl_dev
wget ...

Смотрите http://www.debian-administration.org/articles/566 за интересную статью об этом

Ответ 6

Также проверьте perl-virtualenv, это похоже на обертку вокруг local:: lib, как предложено Hobbs, но создает bin/activate и bin/deactivate, чтобы вы могли использовать его так же, как инструмент python.

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

Это упрощает настройку рабочего виртуального файла для perl, поскольку локальный: lib расскажет вам, какие переменные вам нужно установить, и т.д. perl-virtualenv создает активацию script, которая делает это для вас.

Ответ 7

Я запускаю оболочку CPAN (cpan) и устанавливаю из нее свой собственный Perl 5.10 (Я считаю, что команда устанавливает perl-5.10). Это потребует различной конфигурации настройки; Я не заставляю его указывать на пути в /usr/local (или другое место установки, кроме значения по умолчанию).

Затем я поместил его результирующее местоположение в свой исполняемый файл $PATH перед стандартным perl и использовал его оболочку CPAN для установки необходимых мне модулей (как правило, много). Мои скрипты Perl начинаются с строки

#!/usr/bin/env perl

Никогда не было проблем с этим подходом.

Ответ 8

Похоже, вам просто нужно использовать конфигурацию INSTALL_BASE для Makefile.PL(или опцию --install_base для Build.PL)? Что именно вам нужно для решения? Похоже, вам просто нужно установить установленный модуль в нужное место. Вы представили свою проблему как XY Problem, указав то, что, по вашему мнению, является решением, а не позволяете нам помочь вам с вашей задачей.

См. Например, как сохранить собственный каталог модулей/библиотек? в perlfaq8.

Если вы загружаете модули из CPAN, последняя команда cpan (в App:: Cpan) имеет переключатель -j чтобы вы могли выбирать альтернативные конфигурационные файлы CPAN.pm. В этих файлах конфигурации вы можете установить параметры CPAN.pm для установки там, где вам нравится.

Основываясь на вашем пояснении, это звучит так, как local:: lib может работать для вас в простых простых случаях, но я делаю это для развертывания промышленной силы, где я настраиваю пользовательские, частные CPAN для каждого приложения и устанавливаю непосредственно из этих пользовательских CPANs. Например, см. Мой MyCPAN:: App:: DPAN. Из этого я использую настраиваемые конфигурации CPAN.pm, которые анализируют их среду и устанавливают правильные значения для каждого приложения, могут устанавливать все в каталог только для этого приложения.

Вы также можете рассмотреть возможность распространения приложения как задачи::. Вы устанавливаете его, как и любой другой модуль Perl, но зависимости имеют такую же настройку (то есть INSTALL_BASE).