RE: [Catalyst] How best not to use the system perl
I recently put up an article on my technical blog (brainbuz.org/techinfo). Here's the cut and paste: Installing an Alternate Perl with perlbrew put a current Perl at /usr/bin/perl5. I prefer this solution to the env perl approach many others have chosen. It does require that for your scripts you change the #! line by appending the 5, but it is much easier to append a 5 to the line than remember where your alternate perl is buried in the file system (for scripts run outside your environment). To begin, you’ll need to fire up your system CPAN for its first and only ever run. But even before that you may need to install a few things like gcc. On ubuntu it is as simple as (sudo) apt-get install build-essential. You also need to decide which user is going to maintain perlbrew, it is not unreasonable to choose root, it is also quite reasonable to choose a different user. (sudo) cpan App:perlbrew Say yes to installing dependincies 89 times. There are two tricks you can use to make this a little easier: install App::cpanminus first, it has fewer dependencies and can install perlbrew quietly, alternately Ubuntu Oneric has a perlbrew package, install it and then use perlbrew’s self update option. If installation of perlbew fails, open up a cpan session and type force notest install App::perlbrew. >From this point onwards we consider ourselfs to have 2 perls, our real Perl >(perl5) the system perl which we will never touch, but which is a dependency >for packages needing perl we might have installed. export PERLBREW_ROOT=/opt/perlbrew (/usr/perlbrew and /usr/local/perlbrew are also good choices) perlbrew init /opt/perlbrew/bin/perlbrew available /opt/perlbrew/bin/perlbrew install Using Perl 5.14.1 as an example, type the following two lines ln /opt/perlbrew/perls/perl-5.14.1/bin/perl /usr/bin/perl5 ln /opt/perlbrew/perls/perl-5.14.1/bin/perl5.14.1 /usr/bin/perl5.14.1 This will make Perl5.14.1 your default perl5, and it will give you a specific alias to perl5.14.1 if in the future you need to invoke it specifically you can type perl5.14.1 from anywhere without having to remember the full path. Install cpanminus Now that you have your new perl installed, even though perlbrew has an option to do this I recommend using the cpan in your new perlbrew directory. ./cpan App::cpanminus, configure cpan and answer the prompts. When this is done go to /usr/bin, if you don’t have links there for cpan and cpanm copy them from your new perl’s directory, if you do, they’re just wrappers, edit the #! line to /usr/bin/perl5, so that if in the future you have a newer perl5, you won’t need to touch them. Special case: Padre. Padre requires a multi-threaded Perl, Perlbrew does not build a multi-threaded Perl by default. I update Padre about once a month. You have a two choices, you can tell Perlbrew to build a threaded Perl, or you can leave Padre on your system Perl, which means that you need to make sure that you update it in your system Perl, not your real Perl. If you don’t want a threaded perl a third option would be to build a special threaded perl for Padre (but as long as it works with system perl, why bother?). /opt/perlbrew/bin/perlbrew install \ perl-5.xx.x -Dusethreads -Duselargefiles \ -Dcccdlflags=-fPIC -Doptimize=-O2 \ -Duseshrplib -Dcf_by="Your_name_here" \ -Dcf_email="Your_email@here" -Original Message- From: Dermot [mailto:paik...@googlemail.com] Sent: Friday, September 30, 2011 10:39 AM To: The elegant MVC web framework Subject: [Catalyst] How best not to use the system perl Hi, I have got a new server that I want to put into production. To comply with the manufacturer, I have installed RedHat 6.1 on it. Up till now we have used Debian based machines and have been using the system perl. That worked ok because all the necessay libperl*.deb could be installed via the package manager. That's not an option with yum. I know using the system perl is frowned upon by some so I'd like to do the right thing before the server is deployed. AFAIK, there are two options; 1) install a perl from source into somewhere like /usr/local and set-up the environment so that's the perl that's used or 2) use the system perl (5.10.1) and local::lib. I'm sure there are others with my hardware set-up and I'd be interested in hearing what approached they've taken. Similarly if there are other options to consider or there are strong reasons for using one approach over an other, I'd appreciate hearing them. Thanks, Dermot. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://li
Re: [Catalyst] How best not to use the system perl
On Fri, Sep 30, 2011 at 10:00 AM, Joe Landman < land...@scalableinformatics.com> wrote: > For years, we've been putting our Perl under the > >/opt/scalable/ > > tree. We've run into so many problems with system supplied Perl, that in > general, we simply ignore it. We also have, in the past when we were doing > more Catalyst apps, shipped our baseline tree with everything pre-installed > ... it was *much* easier than going through a build > This is basically what we've been doing at $work, as well -- install our own Perl into /opt/perl (or something like that) with all the dependencies for our applications, pack it into an RPM, then deploy that to our customers' servers. Another thing that hasn't been pointed out is that the system Perl tends to be built in the most pants-on-head moronic way possible. Red Hat, in particular, enables ithreads, which almost nobody uses anymore (due to its faulty design) but incurs a severe performance penalty just for having it compiled in. Anyone that is serious about Perl development should probably be avoiding these builds like the plague. -- Stephen Clouse ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How best not to use the system perl
Hi Dermot, in my development machine I have a Perl environment installed in my home dir with perlbrew. That way I can install anything I need without disturbing (or using) the system perl. Later, when doing a deployment to the production environment, I deploy my app and my full perlbrew environment, directly copied from the development machine. When deploying new versions in the production environment, I simply rename the current version ($HOME/MyApp directory) to MyApp.pre20110930 (date; for example), and I do the same (if needed) to the perl production environment (rename $HOME/perl5 to $HOME/perl5.pre20110930). In this way I have a history of all my deployments (and most important: the previous one). If there's the slightest problem with the new deployment I can switch to the previous version in a matter of seconds. Given the size of today's hard disks, it's no problem to have all these files laying around, and it's saved my life (professional life, that is) sometimes. Regards J. El 30/09/11 16:39, Dermot escribió: Hi, I have got a new server that I want to put into production. To comply with the manufacturer, I have installed RedHat 6.1 on it. Up till now we have used Debian based machines and have been using the system perl. That worked ok because all the necessay libperl*.deb could be installed via the package manager. That's not an option with yum. I know using the system perl is frowned upon by some so I'd like to do the right thing before the server is deployed. AFAIK, there are two options; 1) install a perl from source into somewhere like /usr/local and set-up the environment so that's the perl that's used or 2) use the system perl (5.10.1) and local::lib. I'm sure there are others with my hardware set-up and I'd be interested in hearing what approached they've taken. Similarly if there are other options to consider or there are strong reasons for using one approach over an other, I'd appreciate hearing them. Thanks, Dermot. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How best not to use the system perl
On 09/30/2011 10:52 AM, Stuart Watt wrote: Perl 5.10 isn't really supported any more, so it is highly likely that at some stage the system Perl will get upgraded behind the scenes, breaking binary compatibility with modules even if they are in local::lib. The only safe solution is to use your own Perl (I'd not put it directly under /usr/local, but somewhere application specific, but then I am fairly paranoid). That way, no surprise upgrades will break your application. For years, we've been putting our Perl under the /opt/scalable/ tree. We've run into so many problems with system supplied Perl, that in general, we simply ignore it. We also have, in the past when we were doing more Catalyst apps, shipped our baseline tree with everything pre-installed ... it was *much* easier than going through a build, *especially* due to the inherent brokenness of the WWW::Mechanize modules, and the unfortunate dependencies upon them. We haven't done much with Cat as of late, but we are definitely still shipping our own Perl build (5.12.3 as of now, shortly to move to a 5.14.x by the beginning of the new year). -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics Inc. email: land...@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/sicluster phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How best not to use the system perl
Perl 5.10 isn't really supported any more, so it is highly likely that at some stage the system Perl will get upgraded behind the scenes, breaking binary compatibility with modules even if they are in local::lib. The only safe solution is to use your own Perl (I'd not put it directly under /usr/local, but somewhere application specific, but then I am fairly paranoid). That way, no surprise upgrades will break your application. All the best Stuart On 2011-09-30, at 10:39 AM, Dermot wrote: > Hi, > > I have got a new server that I want to put into production. To comply > with the manufacturer, I have installed RedHat 6.1 on it. Up till now > we have used Debian based machines and have been using the system > perl. That worked ok because all the necessay libperl*.deb could be > installed via the package manager. That's not an option with yum. I > know using the system perl is frowned upon by some so I'd like to do > the right thing before the server is deployed. AFAIK, there are two > options; 1) install a perl from source into somewhere like /usr/local > and set-up the environment so that's the perl that's used or 2) use > the system perl (5.10.1) and local::lib. I'm sure there are others > with my hardware set-up and I'd be interested in hearing what > approached they've taken. Similarly if there are other options to > consider or there are strong reasons for using one approach over an > other, I'd appreciate hearing them. > > Thanks, > Dermot. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] How best not to use the system perl
Hi, I have got a new server that I want to put into production. To comply with the manufacturer, I have installed RedHat 6.1 on it. Up till now we have used Debian based machines and have been using the system perl. That worked ok because all the necessay libperl*.deb could be installed via the package manager. That's not an option with yum. I know using the system perl is frowned upon by some so I'd like to do the right thing before the server is deployed. AFAIK, there are two options; 1) install a perl from source into somewhere like /usr/local and set-up the environment so that's the perl that's used or 2) use the system perl (5.10.1) and local::lib. I'm sure there are others with my hardware set-up and I'd be interested in hearing what approached they've taken. Similarly if there are other options to consider or there are strong reasons for using one approach over an other, I'd appreciate hearing them. Thanks, Dermot. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
