in reply to Avoid using a module if it's not available

Maybe I'm looking at this the wrong way, but your comment,

I have a list of modules I want to use, but only if they're available (i.e. installed on the system the script is running on and included in @INC). If they're not available, I want the code that calls them to be skipped. .... I have about ten different modules I need to use or not-use based on availability.

has me perplexed.

What will your script do (aside from skipping calls) when it runs on a system lacking the modules?

Are you going to reinvent the wheel for each missing module (on who knows how many systems)? Are you going to lift the code from pure perl, non-core modules and insert it in your package? Is one of those or some other workaround in your plan, so your script will function without regard to the target system's lack of one or more of your ten modules.

And how do you plan to distribute your script? (My suspicion is that if you can distribute it and have the sysadmin/owner agree to employ it, you can find a means to get the missing modules installed.)

In short: You've stated your perceived problem clearly, but is it the real problem? (Cf: jdporter's excellent XY Problem.

  • Comment on Re: Avoid using a module if it's not available

Replies are listed 'Best First'.
Re^2: Avoid using a module if it's not available
by akho (Hermit) on Jun 25, 2008 at 15:58 UTC
    I found this node while looking for a way to do exactly what the OP is trying to do, and I believe there are legitimate reasons to do such a thing.

    For example, sometimes you want to use whichever XML parsing module is available.

    Or maybe you want to provide enhanced functionality to people who have some special module installed. Term::ReadLine, for example, lets people on GNU systems do more stuff.

    I need additional modules to reliably guess stuff; my script asks the user for confirmation anyway, so if a good guess is not available — it's not a huge problem, we'll just ask the user.