I'm using perlbrew right now to manage multiple versions of perl, but perlbrew is global. If I do perlbrew switch perl-5.10.1 in any shell, then all shells and scripts will now be using perl version 5.10.1. There is no isolation. Is there any way to make perlbrew switches local to a shell, or is there a similar tool capable of locally changing the active perl?
Just don't use perlbrew. All it's doing is changing symlinks for you. It's supposed to save you work, but when it's not, there's no longer a reason to use it.
I talk about how I do it in Make links to per-version tools in The Effective Perler. I always know which perl I'm using because I never have to remember which one I switched to last, and I don't disturb anything else expecting a particular version behind a symlink. You can still use perlbrew to install perls, but it's not saving you that much work there either.
In more recent versions of Perlbrew, you can do perlbrew use perl-5.12.3 or whatever and you'll be using that version of Perl, but only in the current shell session. Other sessions won't be affected.
Related
I have perl 5.10.1 on my server but I need a higher version of perl than that. I do not have privileges to modify this version so I installed the latest one on my home directory. How do I specify unix to preferentially use the newer version?
The simplest answer is to use perlbrew. This is a tool to install and manage multiple Perl installations in your home directory. You can switch between which one is active.
Follow the instructions on their page to install perlbrew, and then install the latest stable Perl with...
perlbrew install stable
Then tell perlbrew that's the Perl you want to use with...
perlbrew switch stable
If you want to install more modules, use cpanm to install modules to the currently active perl.
cpanm Acme::Pony
If you don't want to use perlbrew, you need to mess with your PATH environment variable. This is a list of directories your shell will search through when finding a program to run. You'd need to put /path/to/where/you/installed/perl/bin at the front. More on this in this article.
I highly recommend you use perlbrew. It takes care of all this for you.
I have a couple of perl modules installed in the $HOME of my web server. The web server used to run perl 5.8.8 so they were installed under $HOME/perl/lib/perl5/5.8.8/...
During a server migration, the web hosting company changed perl to 5.10.1 but I did not know about this until my scripts started failing. I managed to do a quick dirty fix by copying the 5.8.8 tree to 5.10.1 and it seems to work OK now, but I want to avoid my scripts failing like this in future.
What is the best way of allowing my scripts to use the locally stored modules under the 5.8.8 folder even if the perl version gets upgraded again?
I can add a check for the expected perl version in my scripts and email myself if it changes, but it's too late by then as the script may have failed several times before I can fix the problem. Ideally I want to prevent the scripts failing at all.
Depending on the amount of flexibility you have when configuring your environment you may want to use Perlbrew.
to maintain an independent Perl installation at a specific version. This can avoid nasty surprises when the system-wide Perl installation changes.
The thing you really should do is ensure that your needed modules are installed in the new installation. Especially for XS (C-level) modules there is no guarantee that they will run on a new version of Perl without recompiling since the core may have changed.
You should make a Makefile.PL or Build.PL which declares the dependencies of your scripts and you company should make it a policy to execute those scripts on server migration.
Finally, yes you can check $^V which is the running Perl. And if you do it inside a BEGIN block it will be executed during startup. In fact you can use local directories for your (pure perl) modules and then point to them using the lib module.
Why did you move the files at all? Just keep add to PERL5LIB instead.
PERL5LIB=$HOME/perl/lib/perl5/5.10.1:$HOME/perl/lib/perl5/5.8.8
I strongly recommend that you simply use perlbrew to install a build of Perl in your home directory instead of being at your host's mercy.
Searching the web, I have found almost no evidence that perlbrew works on cygwin. The specifics of my current issue are:
With the latest install of cygwin (which includes perl 5.14.2), I'm trying to install perl-5.14.2 using the latest perlbrew, installed from the web (not CPAN). I get a hang just after ../dist/threads-shared/t/shared_attr.t...ok is printed to build.log. This is on WinXP Pro 2002 SP3. Previous tries at using perlbrew on other builds of cygwin (which include perl 5.10.1) have also failed, but in other places.
I have posted a comment on Reini Urban's blog on blogs.perl.org and an issue/bug on github for App-perlbrew, but with no responses yet.
Is there any hope that I can get perl to build on cygwin? If not, what can I do to work around it and still use perlbrew (to unify my environments so that my cygwin environment uses perlbrew, just like my linux environment does)?
perlbrew works and perl can be built on Cygwin, with the minor annoyance that some of the unit tests hang (as you have discovered). Keep one eye on the build process output and kill the tests (usually thread related) that don't do anything for a couple of minutes using ps and kill. perlbrew should (knock on wood) run make install even if a handful of tests did not pass.
I never got perlbrew run under cygwin. But as a workaround perhaps try plenv. When I last tried it, it worked out of the box under cygwin.
A 2018 update - perlbrew works fine for me on Cygwin. However, perlbrew-installed perls will not have the patches that a system Perl has. I have a sample repo at https://github.com/cxw42/perlbrew-on-cygwin showing how I built the latest Cygwin system perl and installed it as a perlbrew perl.
In short, building Perl with prefix, site prefix, and vendor prefix set to ~/perl5/perlbrew/perls/perl-<version> will generate a Perl tree. You can drop that Perl tree into ~/perl5/perlbrew/perls/, and perlbrew will pick it up as an available Perl.
Is it possible to run multiple installs of Perl (in "containers") on one machine?
Reason is that I have different Perl-based server side web applications and wish to schedule updates to them independently.
For example, bugzilla upgrades seem to me to be very invasive, downloading all manner or module updates and lengthy, too (thereby increasing the chance of unpredictable behavior on other applications that depend on those modules, during the time that the upgrade is still partial).
I think it should be possible to run multiple independent server-side CGI Perl applications on one server, I'd rather not be told to separate them onto different machines - I think that's wasteful and I don't have that resource anyway.
Investigate PerlBrew and cpanm:
http://qa.celogeek.com/programming/perl/for/developer/overview
Edit, more info:
http://www.bryanesmith.com/documents/a2pm/perlbrew-june-14-2011.pdf
http://www.dagolden.com/index.php/1384/parallel-make-for-perlbrew/
http://www.perlbrew.pl/
It's easy to install and manage multiple perls. Simply install them in different places and use each perl's tools. I talk about this in The Effective Perler.
Some people suggest perlbrew without realizing that it doesn't really give you any benefit. It can download a perl, configure and install it, and switch around symbolic links to make one of those the default. It doesn't do anything magical, though.
Downloading and installing aren't a problem though. You've never needed root or sudo to do that, and if you do, you'll still need it for perlbrew. You can always install into any directory where you have permission. perlbrew doesn't get around that at all. From the source directory, you have two simple commands to run:
$./Configure -des -Dprefix=/where/you/want/to/install
$ make install
For you, that might mean Bugzilla gets its own perl:
$./Configure -des -Dprefix=/where/you/want/to/install/bugzilla-perl
$ make install
From there, you have a completely self-contained perl installation. When it matters to me which perl I use, I give the program the full path to it:
#!/where/you/want/to/install/bugzilla-perl/bin/perl
It's much easier to make these per-applications installations without perlbrew, which wants to do as much as it can for you, including deciding the directory name, which it prefers you didn't know at all.
perlbrew's main advantage is not the compilation and installation, but it's switch feature to let you make one perl the default. You probably don't want that feature though because you want bugzilla, CGI programs, and so on using only the perl you want them to use, not whatever default perl you last specified.
When you want to update the bugzilla-perl, just use it's tools, which already have adjusted shebang lines to find the right perl:
$ /where/you/want/to/install/bugzilla-perl/bin/cpan ...
I don't like all of those long paths, though, which is why I make links to them all. Then I can just call them with whatever naming scheme I decide, which might be:
$ bugzilla-cpan ...
There's never a question about which tool or version I'm using.
I have been using perlbrew to manage multiple versions of perl on a Linux Fedora notebook. I have used it with great benefit to run command-line scripts mostly using App::cmd.
I now want to move to running web applications written using CGI::Application using different perls installed in my $HOME. I am familiar with running Perl web applications in $HOMEs using Apache's user_dir or creating Virtual Hosts but I am unable to come up with a clean way of integrating this and the perlbrew managed perls. Specifically I need help in understanding and finding answers to these questions:
How do install mod_perl under perlbrew?
Assuming this is done, how do I configure my VirtualHost so that it picks up the correct perl that is current?
If this is not possible, (which I doubt) can I at least use local installations to run vanilla CGI?
Thank you for your attention.
I don't think this is a good use for perlbrew, which moves around symlinks under its own directory. The trick is switching the mod_perl module around. Remember, mod_perl is going to be binary-incompatible between major versions of perl, and that you will have to compile it against apache for each version of perl (and apache) you want to use.
perlbrew really does two big things for you:
Installs perl, which is trivially easy to do on your own.
Switches around symlinks so perl is whatever version you want.
If you give up on that last one, perlbrew isn't really doing that much for you. I don't think the symlink feature is particularly valuable.
I think perlbrew is fine for what it is, but when you start doing things outside of its limited scope, it's time to not use it. It's supposed to be a tool to save you some time and headache, so if it's not accomplishing that goal, it's not the right tool for your situation.
In this situation, where I'm supporting a single, big web application, I give it its own perl installation that I don't let anything else use.
For your other questions:
markdown placeholder
You shouldn't have to configure any VirtualHost stuff. If you are using mod_perl, perl is already in there and you don't get to choose a perl. If you're using CGI stuff, you specify the perl on the shebang line. You will have to ensure apache picks up the right library directories, but I think perlbrew handles that. You might have to use SetEnv or something similar in your httpd.conf.
For vanilla CGI, just point to the right (symlink) path for whatever the default perlbrew version is. The CGI program will just use whatever perl that path points to.
See brian d foy's answer for why not to expect to use perlbrew to switch between versions of mod_perl. I also expect that you will need to run multiple Apache servers, if you need multiple different Perl versions under mod_perl.
However, using perlbrew as an easy way to build Perl is IMHO a valid thing to do, and there are few instructions available for how to run mod_perl under perlbrew.
First ensure perl is built with shared library support, by passing the -Duseshrplib flag (otherwise on 64-bit systems you will get a confusing build failure about -fPIC):
perlbrew install perl-5.16.3 -Duseshrplib
Install the development Apache libraries for your system. On Debian, this differs depending on the Apache MPM that you are using. For the prefork MPM:
sudo apt-get install apache2-prefork-dev
Or for the worker MPM:
sudo apt-get install apache2-threaded-dev
Then you need some options to build and install mod_perl2 into the right place. Note that this means cpanm will fail to build it, but you could use it to get hold of the source:
cpanm mod_perl2 # fails
cd ~/.cpanm/latest-build/mod_perl-2.0.8/ # adjust mod_perl version
Adjust the version of Perl below accordingly. (The MP_APXS option is to give the right path for Debian-based systems, which you might not need.)
perl Makefile.PL MP_APXS=/usr/bin/apxs2 \
MP_AP_DESTDIR=$HOME/perl5/perlbrew/perls/perl-5.16.3/
make
make install
Finally, change the LoadModule line in your Apache configuration file (adjusting paths accordingly):
LoadModule perl_module <your homedir>/perl5/perlbrew/perls/<your perl>/usr/lib/apache2/modules/mod_perl.so
Your mod_perl installation will now be running the version of Perl that you want. Install all your required CPAN modules and get going.