in reply to Re^2: Why does PERL5LIB need to be so verbose? ( INSTALL_BASE the local::lib way)
in thread Why does PERL5LIB need to be so verbose?

this is about installing packages locally, but making them visible globally.

Almost, its about installing them locally and making them visible without extra typing -- what you should be doing

I've no problem installing locally

I think you do have a problem because it looks like you're not using the INSTALL_BASE method; there is a site_perl in your $HOME/perl5

If what you've got is a whole perl installation in your $HOME/perl5 then don't mess with PERL5LIB simply call the correct perl, like $HOME/perl5/bin/perl myapp.pl .... and all those directories will be in @INC already

Or simply use the correct shebang in myapp.pl like #!/h/o/m/e/perl5/bin/perl --

  • Comment on Re^3: Why does PERL5LIB need to be so verbose? ( shebang )

Replies are listed 'Best First'.
Re^4: Why does PERL5LIB need to be so verbose? ( shebang )
by kiz (Monk) on Oct 22, 2013 at 09:32 UTC

    OK - perhaps an explanation of the bigger picture:

    At work, we have Big Iron, and run multiple services from one platform.
    We also install a relatively recent Perl to replace the old one that comes with the OS.

    This means that multiple services, developed by multiple developers, can be using the same core Perl installation.
    This is A Good Thing[tm] as it means only one perl suite needs to be maintained
    This is A Bad Thing[tm] as it means that indiscriminately adding new (or updating!) packages can have consequences for other developers and other services

    It means that the additional packages I want for my service(s), I need to install (and maintain) locally..... things like Mod-Perl, like Catalyst & Moose, like adding & removing various packages until I find the right one for handling .zip files...
    .... but it also means I can install these packages when I want, and not rely on another team to add it to their list of jobs.

    but

    ... this doesn't answer the other interesting question - why is there a proliferation of directories, and what is it that means one goes in one place and another goes somewhere else?

    I install my home-grown packages under /h/o/m/e/perl5/lib/perl/site-perl as they are local to my site.... and not part of CPAN.



    -- Ian Stuart
    A man depriving some poor village, somewhere, of a first-class idiot.
[reply]
[d/l]

      Installing "one Perl" on Big Iron is exactly the reason why the things are distributed across the various directories. If you plan it right, you can run "one Perl executable" and have all Perl libraries mounted under one NFS tree, and the binary Perl extensions will pick up the correct architecture based on the arch string.

      Of course, in practice this only works out in rare cases, and you already know how this can become a configuration nightmare. Nowadays, disk storage is cheap enough to replicate (or install) Perl to every machine instead of launching Perl from a network share.

[reply]
[d/l]

      ... this doesn't answer the other interesting question - why is there a proliferation of directories, and what is it that means one goes in one place and another goes somewhere else?

      Perhaps I'm misunderstanding you, but, is this a real question?

[reply]

        Yes it is....

        For example:
        Why is String::Format under /h/o/m/e/perl5/lib/perl/ whilst Term::ANSIColor is under /h/o/m/e/perl5/lib/perl/5.10.0 and Test::Strict is under /h/o/m/e/perl5/lib/perl/site_perl/5.10.0
        Its not like I'm deliberately installing things in odd ways - sometimes I'll use cpanm and sometimes I'll use perl -MCPAN -e shell



        -- Ian Stuart
        A man depriving some poor village, somewhere, of a first-class idiot.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom