in reply to Re: Using a paramter value to call a module
in thread Using a paramter value to call a module

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.

  • Comment on •Re: Re: Using a paramter value to call a module

Replies are listed 'Best First'.
Re: Re: Using a paramter value to call a module
by Brutha (Friar) on Feb 07, 2003 at 09:44 UTC
    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)

Re: •Re: Re: Using a paramter value to call a module
by Ryszard (Priest) on Feb 07, 2003 at 09:40 UTC
    ++, 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..
      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)

        yes and no.

        Yes it would have been easier if the design had been documented, however no, because the use of the ENV, (in this case) makes the code less portable, and more of a pita to set up on another host - which is independant of the documentation.

        I'm lazy, i like easy systems to install with minimal config changes.