FAQ
A post on Stackoverflow [1] made me notice that perlfaq8 and perlmodinstall
were still recommending "perl Makefile.PL PREFIX=/foo LIB=/foo/lib" rather
than "perl Makefile.PL INSTALL_BASE=/foo" which is predictable and also
installs modules into the same place as "perl Build.PL --install_base=/foo"

The attached patch purges all references to PREFIX from pod/. The patch is
against perlmaint, I recommend its inclusion in 5.8.9 to promote simpler
module installs.


[1]
http://stackoverflow.com/questions/251705/how-can-i-use-a-new-perl-module-without-install-permissions

--
"I went to college, which is a lot like being in the Army, except when
stupid people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz

Search Discussions

  • Michael G Schwern at Nov 6, 2008 at 6:53 am

    Michael G Schwern wrote:
    A post on Stackoverflow [1] made me notice that perlfaq8 and perlmodinstall
    were still recommending "perl Makefile.PL PREFIX=/foo LIB=/foo/lib" rather
    than "perl Makefile.PL INSTALL_BASE=/foo" which is predictable and also
    installs modules into the same place as "perl Build.PL --install_base=/foo"

    The attached patch purges all references to PREFIX from pod/. The patch is
    against perlmaint, I recommend its inclusion in 5.8.9 to promote simpler
    module installs.
    Of course I forgot to attach the patch.

    In addition, I've attached a patch for CPAN.pm to change it's first time
    configuration advice to use INSTALL_BASE rather than PREFIX. I've also
    changed both examples to be installs into the user's home directory which is
    by far the most common scenario.


    --
    87. If the thought of something makes me giggle for longer than 15
    seconds, I am to assume that I am not allowed to do it.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • Graham Barr at Nov 6, 2008 at 12:17 pm

    On Nov 6, 2008, at 12:47 AM, Michael G Schwern wrote:

    A post on Stackoverflow [1] made me notice that perlfaq8 and
    perlmodinstall
    were still recommending "perl Makefile.PL PREFIX=/foo LIB=/foo/lib"
    rather
    than "perl Makefile.PL INSTALL_BASE=/foo" which is predictable and
    also
    installs modules into the same place as "perl Build.PL --
    install_base=/foo"

    The attached patch purges all references to PREFIX from pod/. The
    patch is
    against perlmaint, I recommend its inclusion in 5.8.9 to promote
    simpler
    module installs.
    I am not sure you should purge all references to PREFIX.

    INSTALL_BASE does not allow multiple perl versions to be installed in
    a single
    tree, which is possible with PREFIX when the perl version is included
    in the paths.

    Graham.
  • Michael G Schwern at Nov 6, 2008 at 1:10 pm

    Graham Barr wrote:
    The attached patch purges all references to PREFIX from pod/. The
    patch is
    against perlmaint, I recommend its inclusion in 5.8.9 to promote simpler
    module installs.
    I am not sure you should purge all references to PREFIX.

    INSTALL_BASE does not allow multiple perl versions to be installed in a
    single tree, which is possible with PREFIX when the perl version is included in
    the paths.
    To be clear, there were only three mentions purged (CPAN::FirstTime, perlfaq8
    and perlmodinstall) and both were basic "how do I install a module into my
    home dir" docs. What you're asking is rather more advanced and of narrower
    use. It would have its own FAQ entry.

    FWIW, using PREFIX in that manner is unreliable as it all depends on how each
    Perl was configured. Also it's often not under the user's control. Finally,
    it can change if Perl is reinstalled. This makes it difficult to explain and
    document. Its safer to say INSTALL_BASE=~/perl/<version> or to spell it all out.


    --
    The past has a vote, but not a veto.
    -- Mordecai M. Kaplan
  • Graham Barr at Nov 6, 2008 at 1:25 pm

    On Nov 6, 2008, at 7:10 AM, Michael G Schwern wrote:
    FWIW, using PREFIX in that manner is unreliable as it all depends on
    how each
    Perl was configured. Also it's often not under the user's control.
    Finally,
    it can change if Perl is reinstalled. This makes it difficult to
    explain and
    document.
    I am not advocating that it is reliable, but it is a BIG difference
    between the two
    approaches and IMHO, a missing feature from INSTALL_BASE

    If I am on a machine where I do not control perl, I have to use /path/
    to/perl-x.x.x
    to know that the perl matches my install. But if the system is
    upgraded and I want/need
    to write a new script using a newer perl, I cannot use INSTALL_BASE=~
    anymore because
    it will not work with both existing scripts and new scripts
    Its safer to say INSTALL_BASE=~/perl/<version> or to spell it all
    out.
    But the docs advocate INSTALL_BASE=~ without pointing out this caveat
    and using
    INSTALL_BASE=~/perl/<version> forces a re-install of all modules, not
    just those
    which are architecture, and therefore perl-version, dependent. It also
    means that
    each script know has to know where the library is and include a use
    statement,
    whereas with INSTALL_BASE=~ I can just set PERL5LIB=~/lib/perl5
    whichout having
    to know the perl version

    Graham.
  • Michael G Schwern at Nov 7, 2008 at 2:48 am

    Graham Barr wrote:
    But the docs advocate INSTALL_BASE=~ without pointing out this caveat
    Yes, I agree, it doesn't talk about a lot of things. It's just covering the
    simple question of "how do I install Perl modules if I'm not the system
    administrator" without cluttering it up with a lot of edge cases. That's as
    intended.

    Running multiple versions of Perl in parallel and/or the proper way to upgrade
    Perl and keep your CPAN modules is beyond the scope of that FAQ entry and of
    the perlmodinstall docs I altered. It would need it's own section/FAQ entry.

    I understand what you're saying PREFIX did well [1] and how INSTALL_BASE
    doesn't work as well for that. I maintain about 8 installs of Perl myself,
    but I keep their site_perls separate because it's too much hassle. I don't
    think PREFIX is a good solution, it's too unreliable. I'd suggest instead
    crafting what the interface would look like to DWYM which is independent of
    how Perl is configured.


    [1] When it worked


    --
    44. I am not the atheist chaplain.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
    http://skippyslist.com/list/
  • Matt S Trout at Nov 15, 2008 at 7:04 pm

    On Thu, Nov 06, 2008 at 06:47:52PM -0800, Michael G Schwern wrote:
    Graham Barr wrote:
    But the docs advocate INSTALL_BASE=~ without pointing out this caveat
    Yes, I agree, it doesn't talk about a lot of things. It's just covering the
    simple question of "how do I install Perl modules if I'm not the system
    administrator" without cluttering it up with a lot of edge cases. That's as
    intended.
    I now answer that by saying "here, read the local::lib documentation".

    The nice thing about the environment-variable based approach I use is it
    lets you have as many trees of installed modules as you like with a single
    CPAN(PLUS) config - which (IMNSHO) is even better than what PREFIX offers.

    I'm unsure whether it's considered acceptable for the FAQ to reference
    external modules even as a "here's an alternative you might wish to
    consider" though; if it isn't, then "please feel free to steal any of the
    ideas in local::lib that are useful" and/or "sorry for wasting your time
    and bandwith" (delete as/if applicable).

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Demerphq at Nov 15, 2008 at 7:44 pm

    2008/11/15 Matt S Trout <matt-p5p@trout.me.uk>:
    On Thu, Nov 06, 2008 at 06:47:52PM -0800, Michael G Schwern wrote:
    Graham Barr wrote:
    But the docs advocate INSTALL_BASE=~ without pointing out this caveat
    Yes, I agree, it doesn't talk about a lot of things. It's just covering the
    simple question of "how do I install Perl modules if I'm not the system
    administrator" without cluttering it up with a lot of edge cases. That's as
    intended.
    I now answer that by saying "here, read the local::lib documentation".

    The nice thing about the environment-variable based approach I use is it
    lets you have as many trees of installed modules as you like with a single
    CPAN(PLUS) config - which (IMNSHO) is even better than what PREFIX offers.

    I'm unsure whether it's considered acceptable for the FAQ to reference
    external modules even as a "here's an alternative you might wish to
    consider" though; if it isn't, then "please feel free to steal any of the
    ideas in local::lib that are useful" and/or "sorry for wasting your time
    and bandwith" (delete as/if applicable).
    Howabout we just core local::lib?

    Yves


    --
    perl -Mre=debug -e "/just|another|perl|hacker/"
  • John P. Linderman at Nov 6, 2008 at 4:42 pm

    Graham responded to Michael thusly:
    On Nov 6, 2008, at 7:10 AM, Michael G Schwern wrote:

    FWIW, using PREFIX in that manner is unreliable as it all depends on
    how each
    Perl was configured. Also it's often not under the user's control.
    Finally,
    it can change if Perl is reinstalled. This makes it difficult to
    explain and
    document.
    i am not advocating that it is reliable, but it is a BIG
    difference between the two approaches and IMHO, a missing
    feature from INSTALL_BASE

    If I am on a machine where I do not control perl, I have to use
    /path/to/perl-x.x.x to know that the perl matches my install.
    But if the system is upgraded and I want/need to write a new
    script using a newer perl, I cannot use INSTALL_BASE=~ anymore
    because it will not work with both existing scripts and new
    scripts
    Its safer to say INSTALL_BASE=~/perl/<version> or to spell it all
    out.
    But the docs advocate INSTALL_BASE=~ without pointing out this
    caveat and using INSTALL_BASE=~/perl/<version> forces a
    re-install of all modules, not just those which are
    architecture, and therefore perl-version, dependent. It also
    means that each script know has to know where the library is and
    include a use statement, whereas with INSTALL_BASE=~ I can just
    set PERL5LIB=~/lib/perl5 whichout having to know the perl
    version

    Graham.
    Having just done battle with PREFIX= and PERL5LIB
    (I had to do all sorts of ugly things with Config
    to find all the subdirectories of the PREFIX that
    stuff might turn up in so I could set PERL5LIB),
    I'd switch to INSTALL_BASE= in a heartbeat if
    it meant I could just include the one directory
    in my PERL5LIB. Can I expect it to work with
    almost any CPAN module and perl release,
    or does it rely on relatively recent stuff? -- jpl
  • John Siracusa at Nov 6, 2008 at 4:52 pm

    On 11/6/08 11:42 AM, John P. Linderman wrote:
    Having just done battle with PREFIX= and PERL5LIB (I had to do all sorts of
    ugly things with Config to find all the subdirectories of the PREFIX that
    stuff might turn up in so I could set PERL5LIB), I'd switch to INSTALL_BASE=
    in a heartbeat if it meant I could just include the one directory in my
    PERL5LIB.
    That drives me crazy too, but the arch-dependent dirs are probably not going
    away[1]. The "lib" module can help here. Just "use lib '/foo/bar'" then
    peek in @INC to see the list of paths you need to add to PERL5LIB for that
    "one" directory you're trying to add to @INC. The only catch is that the
    subdirectories have to actually exist, since lib.pm checks for them with -d.
    Look at the source for lib.pm for the details:

    http://search.cpan.org/src/SMUELLER/lib-0.61/lib_pm.PL

    -John

    1. FWIW, if people are open to the auto/arch/version/whatever subdirs going
    away (or being automatically searched by perl without having to be in @INC)
    I'd be all for that too :)
  • John P. Linderman at Nov 6, 2008 at 6:39 pm

    John Siracusa shared my pain:
    On 11/6/08 11:42 AM, John P. Linderman wrote:
    Having just done battle with PREFIX= and PERL5LIB (I had to do all sorts of
    ugly things with Config to find all the subdirectories of the PREFIX that
    stuff might turn up in so I could set PERL5LIB), I'd switch to INSTALL_BASE=
    in a heartbeat if it meant I could just include the one directory in my
    PERL5LIB.
    That drives me crazy too, but the arch-dependent dirs are
    probably not going away[1]. The "lib" module can help here.
    Just "use lib '/foo/bar'" then peek in @INC to see the list of
    paths you need to add to PERL5LIB for that "one" directory
    you're trying to add to @INC. The only catch is that the
    subdirectories have to actually exist, since lib.pm checks for
    them with -d. Look at the source for lib.pm for the details:

    http://search.cpan.org/src/SMUELLER/lib-0.61/lib_pm.PL

    -John

    1. FWIW, if people are open to the auto/arch/version/whatever
    subdirs going away (or being automatically searched by perl
    without having to be in @INC) I'd be all for that too :)
    There's a chicken-and-egg problem for me. I'm trying to
    set up a "wrapper" that sets up all sorts of environment
    variables, PERL5LIB among them, so I just change the
    #! line without having location-specific use lib stuff
    in the scripts I'm porting. That happens first, before
    any of the CPAN modules get installed (via scripts).
    So there won't be any funny directories when I'm
    configuring the wrapper.

    Another alternative would be to have yet another Config
    variable that identifies all the subdirectories that
    should be added to a base PREFIX/INSTALL_BASE to find all
    places stuff might get dropped. In effect, that's what
    I'm doing now, looking for all the prefix-like Config
    variables, like
    my @PrefixConfigs = qw(
    prefix prefixexp
    installprefix installprefixexp
    siteprefix siteprefixexp
    vendorprefix vendorprefixexp
    );
    and then looking for install-like Configs of which they
    are a prefix.
    my @InstallConfigs = qw(
    installarchlib installprivlib
    installsitearch installsitelib
    installvendorarch
    installvendorlib
    );
    Remove the prefix from the install dirs, and you get relative
    subdirectories to paste on. It seems to work (on a few
    architecture/perl release combinations where I've tried it),
    but it's a definite kludge. Nicer if it were done already
    in the Config. But even that wouldn't help short term,
    because I need to have something that works with existing
    Config's, not just those in 5.10 or later. -- jpl

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedNov 6, '08 at 6:48a
activeNov 15, '08 at 7:44p
posts11
users6
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase