Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

How should I manage CPAN when using two versions of Perl in my computer?

by hda (Chaplain)
on Jun 17, 2018 at 17:16 UTC ( [id://1216816]=perlquestion: print w/replies, xml ) Need Help??

hda has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks!

I normally use two different versions of Perl on my computer: one that comes with the Linux distro (openSUSE) I use and another one that I use to write scripts and mess with, and that I normally compile myself from source. The reason I do this is to not introduce changes in the system's installation and potentially brake things beyond my knowledge on how to repair.

Until now I have done the quick & dirty procedure of just relying on my (usually more up to date) installation and neglect the system's Perl. However I realize that this is possibly not the soundest strategy. My question then is how should I best manage module installation and update using CPAN in these different installations?

The CPAN executables live in different folders and (I believe) are compiled to point to different sets of libraries. These executables can be called separately (/usr/bin/cpan; or /usr/local/bin/cpan). Now, CPAN requires a sort of environment (i.e. /root/.cpan/...). Both executables seem to use this same environment, but apparently these two CPAN realize the different upgrading needs (for example when calling "r").

How does this impact in the update of modules? Should I aim to create different CPAN work directories? Are there any recommendations out there on how to proceed with this?

Any hint will be appreciated.

Thanks in advance.

Replies are listed 'Best First'.
Re: How should I manage CPAN when using two versions of Perl in my computer?
by atcroft (Abbot) on Jun 17, 2018 at 20:40 UTC

    I am curious-since you are on a *nix-based system, have you considered using perlbrew (here or here) as a way to manage the (possibly multiple) "local" installation(s)?

    Also, remember that you can have a local CPAN configuration (via the 'mkmyconfig' command) so your user can have a CPAN configuration apart from the system CPAN configuration.

    Hope that helps (and looking forward to the potential answers to this question).

      I have the exact same situation with OSX: there is a native perl that system relies on and my own updated version. perlbrew was the way to go for me.

      Now, use of perlbrew, requires to set an env-var and use #!/usr/bin/env perl as the shebang of all your perl scripts. Do you have to mess with system's perl scripts, or Apache's etc. and change their shebangs to this new env thingy? Most likely no. This is just a warning from me and very likely a false alarm!

      Because from my experience on OSX, I use perlbrew but the system still uses its own perl without me ever needed to mess with system's shebangs. So, in my case perlbrew works as I and the system expect it, but you should confirm that perlbrew will not require you to change anything in system's perl scripts neither require Apache or cron or whatever to setup perlbrew-specific env-vars.

      Btw, this came up in a search : https://stackoverflow.com/questions/4764025/how-to-specify-which-version-of-perl-to-use-on-centos

      Second caveat is of course the use of perl-command switches in the shebang (e.g. #!/usr/bin/perl -w). You will find that your new shebang #!/usr/bin/env perl -w does not work in linux (expected behaviour, you must remove the '-w' at the end and find a way to put it somewhere else. Where? Someone knows a definite guide on this?) but works in OSX (BSD-based), see here: shebang anomaly

      Once using perlbrew, you may also want to install modules using cpanm (App::Cpanminus) rather than cpan. Great program! Transparent and efficient: cpanm install Test::More

      Alternatively and for the sake of completeness, I mention update-alternatives. It is the linux-specific way to handle multiple versions of the same program, e.g. gcc. I have used it with gcc and java and never had any problem. Though I never bothered to learn more about it than copy-paste some one-liners from net. I assume it can handle all these because gcc/java, just like perl, rely on other programs, libraries, installation paths etc.

        Regarding the "shebang anomaly", perlrun indicates that:

        • -w
          prints warnings about dubious constructs, such as variable names mentioned only once and scalar variables used before being set; redefined subroutines; references to undefined filehandles; filehandles opened read-only that you are attempting to write on; values used as a number that don't look like numbers; using an array as though it were a scalar; if your subroutines recurse more than 100 deep; and innumerable other things.
          This switch really just enables the global $^W variable; normally, the lexically scoped use warnings pragma is preferred. You can disable or promote into fatal errors specific warnings using __WARN__ hooks, as described in perlvar and warn. See also perldiag and perltrap. A fine-grained warning facility is also available if you want to manipulate entire classes of warnings; see warnings.

        I would think if you update the script to use warnings you should be okay in removing the '-w' from the shebang line (although if I am wrong, please respond, so I can learn from the mistake!).

        Hope that helps.

        use of perlbrew, requires to set an env-var and use #!/usr/bin/env perl as the shebang of all your perl scripts.

        I love perlbrew but I love the shebang more. I could not look at env at the top of every perl script let alone type it. Shebang is holy and I found an easy way to preserve it to an acceptable degree and gained a very handy perlbrew switch. Like many others I have an untouched system perl and a main perlbrew with tons of cpan modules. My shebang preservation and toggle switch between system perl and perlbrew perl is achieved by making a symlink in the root directory called "user" that points to the main perlbrew path:
        
        cd /
        sudo ln -s /path/to/perl5/perlbrew/perls/perl-VERSION user
        
        
        The main perlbrew path is found by typing "which perl" while brewing the main perlbrew perl and ignoring the /bin/perl part at the end. Now there are two shebangs with a single character switch that works everywhere:
        
        #!/usr/bin/perl  # system perl
        #!/user/bin/perl # perlbrew perl
        
        
        On my system:
        
        /usr/bin/perl -le 'print $^V'
        v5.18.2
        
        /user/bin/perl -le 'print $^V'
        v5.26.2
        
        
        This symlink has made me very happy! ☺

        STOP REINVENTING WHEELS, START BUILDING SPACE ROCKETS!CPAN 🐪
      Thanks for that. I am not familiar with perlbrew. I'll have a look.
Re: How should I manage CPAN when using two versions of Perl in my computer?
by dave_the_m (Monsignor) on Jun 17, 2018 at 18:41 UTC
    In general, with Linux distributions, you should avoid using the cpan utility to install modules to the system perl, and instead rely on the OS packaging system's pre-packaged cpan distributions. For example on my Fedora system I would install the 'perl-Mozilla-CA' rpm using dnf, rather than doing '/usr/bin/cpan Mozilla::CA'. I can't comment specifically on how openSUSE handles things.

    Dave.

      Thanks for your answer, Dave. Indeed, that seems like a very sound strategy.
Re: How should I manage CPAN when using two versions of Perl in my computer?
by choroba (Cardinal) on Jun 17, 2018 at 21:35 UTC
    I use openSUSE, too. I usually install new libraries to system perl viz zypper as root, but if they're missing, I use CPAN with local::lib as the normal user. I have several more Perl versions istalled, too (including blead), I compile them from sources by hand. To use them, I just
    unset ${!PERL*}

    to remove the local::lib settings, then run /path/to/perl5.XX/bin/cpan and it will install the modules into the correct path where the corresponding perl will find them.

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
      Thanks. Very interesting approach. I'll have a look at local:lib.
Re: How should I manage CPAN when using two versions of Perl in my computer?
by syphilis (Archbishop) on Jun 18, 2018 at 00:30 UTC
    Should I aim to create different CPAN work directories?

    No ... though you can if you want to.

    I have multiple perl installations with different configurations and version numbers, and they all use ~/me/.cpan as their CPAN build directory.
    It has never been an issue on Linux for me.

    On Windows, it's the same situation - though I did have to make a small hack to .cpan/CPAN/MyConfig.pm.
    Because some of the windows perls use different flavours of "make" I had to change 'make' => q[make] to 'make' => $Config{make} (which, IIRC, meant that I also had to insert use Config; into MyConfig.pm).

    Cheers,
    Rob
      Yes, this is the behaviour I have also observed. Nice that CPAN does not need another work directory. Thanks for your response.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1216816]
Front-paged by haukex
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-03-29 11:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found