in reply to Using a paramter value to call a module

'use' is processed at compile time. If you need to include modules at runtime, use 'require'. There are some other differences between the two so look them up in the documentation. For one thing, 'use' may import symbols from the module automatically. You need to call the module's import method yourself if you use 'require'.

Why are you using 'use lib'? You shouldn't need to do this for properly installed modules. If this is a library of your own modules, you might be better off using an environment variable such as PERLLIB or PERL5LIB to locate these rather than embedding the path in all your programs.

---
print map { my ($m)=1<<hex($_)&11?' ':'';
$m.=substr('AHJPacehklnorstu',hex($_),1) }
split //,'2fde0abe76c36c914586c';

[download]

Replies are listed 'Best First'.
•Re: Re: Using a paramter value to call a module
by merlyn (Sage) on Feb 07, 2003 at 05:44 UTC
    If this is a library of your own modules, you might be better off using an environment variable such as PERLLIB or PERL5LIB to locate these rather than embedding the path in all your programs.
    Nope, because even though you might be setting that variable, there's no guarantee that someone else running your program has that same variable set. But if you use lib, then everyone wins.

    use lib is generally preferred to an environment variable for this reason.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
      Ooops,

      merlyn, I do not belive that. Please explain further, because I would say everybody looses if you use lib.

      My experience tells me, to avoid hardcoded variables whenever possible, especially paths to files, for the following reasons:

      1. if you move the script, it possibly does not run anymore, the path does not exist for a different user on the network. So you have to modify the script and have dozens of version after a while. (Think of big networks, different usergroups with access rights etc.)

      2. You have a testbed with your modules and a different production environment. You will have to modify your programm after the release-test.For the stuff with legal impacts, I will never get through revision, even if I do the same with PERL5LIB, because of the remaining risk of further changes.

      3. use lib is at the beginning, other constants maybe not, but somewhere hidden in a module etc. This is hard to maintain.

      4. You have a well coded script, that can be used for different purposes, you change a setting in an ini-file instead of the code itself.

      5. customization or internationalization can be solved with a module on a different path (use Perl code to set constants). You have to switch the path maybe repeatedly.

      etc. etc.

      But for the use lib; I consider the discussion not necessary, because it is quite easy to avoid it most times:
      - have the modules in a subdirectory
      - install them properly, so they are in .../site/lib and in the path beneath the runtime.

      --
      And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
      (Terry Pratchett, Small Gods)

[reply]
      ++, I'm in the unfortunate position of having to support and migrate some perlies that rely heavily on environment variables. Moving these into a production environment has been made more difficult than necessary by poorly implemented and documented code..
[reply]
        Sorry, but do you really think, it would have been easier, if the values had been hard-coded?

        The problem is the documentation, not the use of environment variables. Depending on the amount, it could have been better to put them in a file instead of the environment, but that is a problem with the code, not the use of variables.

        --
        And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
        (Terry Pratchett, Small Gods)

[reply]

In Section Seekers of Perl Wisdom