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

I doubt I'm the first person to ask. I'm hoping to get it all in once place if nothing else -- though, I was unable to find much on here using the regular search.

I wish to test some stuff on a test account on a lunix box that I don't own. I found out that it's exceedling trickey to install modules as non-root. I don't think it should be.

The first problem, the admin had already configured CPAN, so the CPAN::Config pointed to /home/adminname/.cpan and I couldn't even start the shell. :(

How can you reconfigure CPAN to use ~/.cpan once the real admin has already configured it?

The second problem is the @INC. Is there a way to fool a root-installed binary into adding your ~/my-mods to @INC? I keep looking for an environment variable for this, but there doesn't seem to be one. Yeah, I can add -I ~/my-mods to everything...

Is there a transparent way to globally modify @INC?

Of course, I can always just build my own perl, but that seems cheap and lame to me. Also, then the #!/usr/bin/perl won't work.

Replies are listed 'Best First'.
Re: CPAN non-root questions
by matija (Priest) on Apr 02, 2004 at 17:10 UTC
    To quote perldoc cpan:
    The default values defined in the CPAN/Config.pm file can be overridden in a user specific file: CPAN/MyConfig.pm. Such a file is best placed in $HOME/.cpan/CPAN/MyConfig.pm, because $HOME/.cpan is added to the search path of the CPAN module before the use() or require() statements.

    The second problem is the @INC. Is there a way to fool a root-installed binary into adding your ~/my-mods to @INC?

    Well, you could set PERL5LIB before you run that binary.

    Is there a transparent way to globally modify @INC?

    What do you mean by "globaly"? For every process run by a specific user? Set PERL5LIB in that user's login script (actual syntax and filename depends on that user's shell).

    Update: (Thanks to borisz): meant to write PERL5LIB, wrote PERL5INC instead. Apologies for the bainfart.

[reply]
      Sorry, by globally I meant for all processes run by that user. So, you're guess was 100% correct. Also, your post answered all my questions. Thanks.
[reply]

      matija arose from serene meditation and wisely quoth:

      To quote perldoc cpan:
      The default values defined in the CPAN/Config.pm file can be overridden in a user specific file: CPAN/MyConfig.pm. Such a file is best placed in $HOME/.cpan/CPAN/MyConfig.pm, because $HOME/.cpan is added to the search path of the CPAN module before the use() or require() statements.

      IIANM there are two situations under which the ~/.cpan/CPAN/MyConfig.pm file and its parent dirs can come to exist:

      1. The user is the first one to ever run CPAN.pm on that perl installation (hey, it can happen, on a not-uncommon single-user workstation setup), or
      2. The user does what has been cited above, explicitly creating the ~/.cpan/CPAN/MyConfig.pm file and manually editing the contents to create appropriate settings. In many cases (altho I believe it is not suggested explicitly in the Fine Documentation for CPAN.pm), the sensible thing to do is to copy the system-wide Config.pm file from wherever it resides, into one's private dir. Then "guess" at what the changes needed should be.

      In the case (1) above, when CPAN.pm is invoked in the usual manner (on older perls, typically by doing perl -MCPAN -e shell, and on newer ones by just using the wrapper script named 'cpan' which does the same thing internally) .. in that case the obligatory (and lengthy, and often confusing for new perl users) setup interaction will suggest that such a file will be created when the user is done with the interroga .. er, dialogue.

      IMHO this is all a little bit harder than it ought to be. I could describe the points in detail now but will save it for another time (especially since I've been working on a project that addresses this very area).

      If I am mistaken on any of the factual points (non-subjective, as contrasted with characterizations like "harder than" or "confusing") I would appreciate being corrected. Cheers,

          Soren A / somian / perlspinr / Intrepid

[reply]
Re: CPAN non-root questions
by z3d (Scribe) on Apr 02, 2004 at 18:09 UTC
    Unless I'm totally misunderstanding your question, this is all covered in the CPAN FAQ. http://www.cpan.org/misc/cpan-faq.html#How_install_private

    In short, you can govern where the files are built to on the command line. You can override the default cpan config file by simply creating a .cpan directory structure and config file in your home directory. Pretty sure all of that is covered in the CPAN faq though.


    "I have never written bad code. There are merely unanticipated features."
[reply]
      No you got it right. I checked the faq, I'm apparently just mildly illiterate. Well, I used perldoc -q. I never really thought to check the CPAN website. That's an excellent link.
[reply]
[reply]
[d/l]
Re: CPAN non-root questions
by toma (Vicar) on Apr 03, 2004 at 06:26 UTC
    Maybe this will make you feel less cheap-and-lame: you might get a substantial speed improvement by compiling your own perl. My perl build is about 30% faster than my vendor perl.

    My private perl allows me to install modules without worrying about breaking system utilities that rely on old versions of perl and modules. This actually happened to a friend of mine once. He had the system version of perl restored, and I had to switch to my own private build.

    Some people, who I greatly respect, share your disdain for using a perl that is different from /usr/bin/perl, and I'm still wondering why that is. I've never heard a rational explanation for it. I'll build a new perl at the drop of a hat!

    It should work perfectly the first time! - toma
[reply]

Back to Seekers of Perl Wisdom