Re: conditionally loading modules

[Chet the Extra-Strength Nairobian Death Monkey <mortis@voicenet.com>]

On Fri, Aug 25, 2000 at 01:40:32PM -0400, Darxus@chaosreigns.com wrote:
> This is bothering me, and I feel like telling somebody about it.
> 
> I still consider myself relatively new at perl, but in each of the 3
> programs I've written that I felt were worth posting to freshmeat, I've
> used a module that is not part of the default perl install.  Because the
> module is not on all systems, and because the program could still do
> useful things without the module, I want to test for its presence, and
> load it if I can, and deal if I can't.

Very admirable behavior IMO.

> Perl does not seem to like this idea very much.  That's what's bothering
> me.

If your software has a configure, or a 'build' process, you could 
verify the existance of the module:

  perl -MSome::Module -e '$x=1;'>/dev/null 2>&1

which will return success/failure so you can detect it.  This of course doesn't
deal with the desire to handle the module not being there -- but you 
could possibly use it to assemble different versions of your program -- 
dikeing out the code that uses the module, if it's not available, producing
a copy of your program that has less lines of code than the fully functional
one -- you could use the C preprocessor to do that, or just search/replace
regexes with a build script you write...

> Beyond the possibility that I may have just overlooked something, there is
> the fact that when I was looking very actively, I found it very hard to
> find information on this subject.
> 
> Sure, you can do 
> 
> $gnupg = eval "require 'GnuPG.pm';"
> 
> And then check $gnupg before attempting anything gpg related.  I'm fine
> with that.  It's a little odd, and I don't think particularly well
> documented, but somebody (Kyle) showed me how to do it, and I can use it.
> 
> The problem comes with stuff like Date::Calc.  If you require() it, it
> doesn't import its functions, and it gives you errors saying that its
> functions aren't defined when you try to use them.
> 
> The answer I've come up with is this:
> 
> if (eval "require Date::Calc;")
> {
>   import Date::Calc;
>   $dow = 1;
> } else {
>   print STDERR "Connot find Perl module Date::Calc, not generating Day Of Week stats.\n";
>   $dow = 0;
> }
> 
> The significant part is the import().  It took reading its section of the
> perlfunc man page quite a few times, and a lot of trial and error to make
> it work.  The fact that perl seems to not bother reporting errors for
> these things didn't help.
> 
> It seems to me that at some point in writing a program, every coder should
> sit back and think "hmm, what modules that I'm using could this program
> function without ?", and then load them conditionally, and deal with their
> absence.  This should be a common coding practice, and well documented.

Another (probably less than optimum) possibility is for you to provide
skeleton, or no-op versions of these functions in the even that the module
isn't available.  Create a dummy Date::Calc module that you can use in
the case that the real Date::Calc won't stand up.  Since the functions are
exported, you dont' even have to call the module Date::Calc, it just has
to export the functions.


I think in all the occasions that I've written code that requires an external
module (even CPAN modules), I've just documented that fact and expected the
person using/installing my code to get the needed modules.  

I think if I was in your shoes, I might use a pre-process to modify the
program's source code to handle the existance or absence of the module.


just a few thoughts/opinion...

k

-- 
------------------------------------------------------------------------------
"From a certain point onward there is no longer any turning back.  That is the
 point that must be reached."   -- Kafka
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------
**Majordomo list services provided by PANIX <URL:http://www.panix.com>**
**To Unsubscribe, send "unsubscribe phl" to majordomo@lists.pm.org**