Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Installing modules to a private module directory

by Dominus (Parson)
on Apr 21, 2008 at 20:34 UTC ( #682025=perlmeditation: print w/replies, xml ) Need Help??

This is a Frequently Asked Question. Unfortunately, most of the Frequent Answers either don't work, suck, or suck and don't work.

I recently adopted a very simple solution that does work pretty well. The summary is:

  1. Forget about using "make install".
  2. Just run "make".
  3. cp -pr Module/blib/lib/* private/lib/.

More complete details available from my blog. I hope this is useful for someone.

  • Comment on Installing modules to a private module directory

Replies are listed 'Best First'.
Re: Installing modules to a private module directory
by tinita (Parson) on Apr 21, 2008 at 20:42 UTC
    do you have an example where
    perl Makefile.PL PREFIX=/dir LIB=/dir
    does not work? i didn't find one in your blog.

      It was quite recently reported again that Module::Build still hates PREFIX= (despite it having been quite a while since the last time I heard rumor of somebody going to teach its author how to handle PREFIX= in a reasonable way). Perhaps the report is due to an old version of the module being used, but I suspect not. (And, yes, "perl Makefile.PL" 'should' work even if Module::Build was used, that is, so long as you don't specify PREFIX=.)

      Of course, I don't have to strain at all to imagine cases where "cp -pr ..." would fail.

      - tye        

        I guess you refer to my report. The version of Module::Build was as you suspect recent:
        perl -MModule::Build -e 'print "$Module::Build::VERSION \n";' 0.2808

        It was no big deal doing a perl --install_base ~/perl5lib, other than having to resolve a couple of dependencies the same way before succeding. I'd really like to get that .modulebuildrc configured correctly to avoid the hassle.

        Now, I'm not sure if I find it a relief or terifying that issues like these even annoys people like Dominus, who are not a just litle bit smarter and more knowlegdable than I am.

        It will be interesting to see if the method he describes on his blog works for me. If it does, it can't be to hard to make a nice litle script for it.

      i didn't find one in your blog.
      Did you actually try this? I did, and it fails, for reasons I did explain in the blog. ("...the first thing everyone says is that you can just set PREFIX to X. No, because...")

        Instead of PREFIX, you can use INSTALL_BASE, which I believe is now the perferred option for Module::Build and ExtUtils::MakeMaker (so long as you have up-to-date versions of both). I haven't had a problem with this, altho I haven't installed all of CPAN with it.

        You still run into the problem of setting your @INC, since things seem to randomly install in a subdirectory called either 'site_perl', 'perl5' or '5.x.x', meaning you have to add 3 entries to your @INC. This can be annoying if your paths can change depending on the box you're working on.

        Did you actually try this?
        otherwise i wouldn't ask.
        maybe i just don't get it, but it has always worked for me to install my modules with setting PREFIX and LIB. i just asked for an example. show me a module where it doesn't work. that's all i asked for. i would be really interested because i use the PREFIX/LIB method for my cgipan script and i would like to correct it if it has got a mistake.
        in your blog you gave the reason why it doesn't work to set PREFIX. but you didn't say that using PREFIX and LIB together fails.
Re: Installing modules to a private module directory
by Anonymous Monk on Apr 22, 2008 at 14:33 UTC
    ExtUtils::Install is for blib
    D:\> md extutils-installed-t D:\> cd extutils-installed-t D:\extutils-installed-t> D:\extutils-installed-t>h2xs -AXn Testi Defaulting to backwards compatibility with perl 5.8.7 If you intend this module to be compatible with earlier perl versions, + please specify a minimum perl version with the -b option. Writing Testi/lib/ Writing Testi/Makefile.PL Writing Testi/README Writing Testi/t/Testi.t Writing Testi/Changes Writing Testi/MANIFEST D:\extutils-installed-t>cd Testi D:\extutils-installed-t\Testi>perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for Testi D:\extutils-installed-t\Testi>nmake test Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. cp lib/ blib\lib\ D:\perl\theoryx5\Perl\bin\perl.exe "-MExtUtils::Command::MM" " +-e" "test_harness(0, 'blib\lib', 'blib\arch')" t/* .t t/Testi....ok All tests successful. Files=1, Tests=1, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 C +PU) D:\extutils-installed-t\Testi>perl -MExtUtils::Install -e "install({ @ +ARGV } )" blib/lib ../daBOMBlib Installing ..\daBOMBlib\ D:\extutils-installed-t\Testi>cdt .. D:\extutils-installed-t>perl -IdaBOMBlib -MTesti -e"die Testi->VERSION +" 0.01 at -e line 1. D:\extutils-installed-t>tree /f /a D:. | +---daBOMBlib | | \---Testi | Changes | Makefile | Makefile.PL | MANIFEST | pm_to_blib | README | +---blib | +---arch | | | .exists | | | | | \---auto | | \---Testi | | .exists | | | +---bin | | .exists | | | +---lib | | | .exists | | | | | | | | \---auto | | \---Testi | | .exists | | | +---man1 | | .exists | | | +---man3 | | .exists | | | \---script | .exists | +---lib | | \---t Testi.t D:\extutils-installed-t>
      The doc say
      Both install() and uninstall() are specific to the way ExtUtils::MakeMaker handles the installation and deinstallation of perl modules. They are not designed as general purpose tools.,
      but its de-facto standard (same as blib), both Module::Install and Module::Build use it.
Re: Installing modules to a private module directory
by naikonta (Curate) on Apr 28, 2008 at 15:24 UTC
    First of all, now I'm really sure that I'm not the only one who has need of including non standard CPAN modules in the application distribution as I presented in my meditation. Further, my situation was, even if the target host did have one or more of the modules, I inclined that the application used the ones in its private lib dir.

    After struggling with docs from ExtUtils::MakeMaker and Module::Build, I managed to install the modules with the following command:

    perl Makefile.PL INSTALLDIRS=perl PREFIX=/path/to/appl/lib LIB=/path/t +o/appl/lib make make install

    Well, I think that covers the first three ways you are informed about. While the other two gave me permission error (as a normal user), only PREFIX installed smoothly. However, it layout its stuffs (lib, share, man, bin) under /path/to/appl/lib.

    I somehow insisted on using so-called "standard mechanism" but failed to prevent the extra stuff from spring. One thing I noticed was I also got i486-linux-gnu-thread-multi directory for, I thought, XS modules. I don't think I would get this directory with your cp -pr approach, but I believe that directory is just a fancy place for whatever it is.

    Fortunately, I didn't get any problem regarding PREFIX. It just worked.

    Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://682025]
Approved by kyle
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2022-05-27 19:05 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (97 votes). Check out past polls.