Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

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
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 Build.pl --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/Testi.pm 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/Testi.pm blib\lib\Testi.pm 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\Testi.pm 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.pm | \---Testi | Changes | Makefile | Makefile.PL | MANIFEST | pm_to_blib | README | +---blib | +---arch | | | .exists | | | | | \---auto | | \---Testi | | .exists | | | +---bin | | .exists | | | +---lib | | | .exists | | | Testi.pm | | | | | \---auto | | \---Testi | | .exists | | | +---man1 | | .exists | | | +---man3 | | .exists | | | \---script | .exists | +---lib | Testi.pm | \---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?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2014-08-01 06:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (257 votes), past polls