in reply to Why does PERL5LIB need to be so verbose?

1. What is the rational for the proliferation of directories.... and why do I need to specify all of them in PERL5LIB?

Choice is choice, and you seem to have picked the extra VERBOSE choice, and mixed it with something else ....

Why can't Perl expand /home/services/foo/perl5/lib/ as it does for the default library path?

You only have to add one path to @INC if you do it the INSTALL_BASE way ( local::lib way ) as demonstrated in Re^3: object version does not match bootstrap parameter ( cpanm --local-lib PERL5LIB)

  • Comment on Re: Why does PERL5LIB need to be so verbose? ( INSTALL_BASE the local::lib way)

Replies are listed 'Best First'.
Re^2: Why does PERL5LIB need to be so verbose? ( INSTALL_BASE the local::lib way)
by kiz (Monk) on Oct 22, 2013 at 07:44 UTC

    From what I think I read (well, I read - its the understand that harder :chuckle: ) this is about installing packages locally, but making them visible globally.

    I've no problem installing locally, and I need them to remain local - an example is Mod-Perl: this compiles against a specfic apache install, so you cannot use the Mod-Perl packages installed in the library path with any other apache server...

    .... on the other hand, I think it has sparked enough for me to get a more concise PERL5LIB: export PERL5LIB=$HOME/perl5/lib/perl5:$HOME/perl5/lib/perl5/site_perl



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

      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 --

[reply]

        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]

In Section Seekers of Perl Wisdom