If memory is an issue, traversing @INC may be your best option. Anyway, to answer the question - assuming you're dealing with Some::Module, you would simply delete $INC{'Some/Module.pm'} although you may also need to delete it from the overall symbol table: undef ${Some::Module::} - that last part is untested, and I'm sure someone will correct me with the right way to do that. If it's possible. Which is why I go back to traversing @INC as your most memory-conscious choice, although because you won't be compiling it, its mere presence, even if it doesn't compile, will give you a different answer (probably not important, but I like to keep all the risks, however small, on the table, in case they are not small to you).

If memory is an issue, traversing @INC may be your best option.

So if I used File-Find to traverse @INC, looking for Some::Module, that would be faster and more efficient that using a require within an eval? I keep thinking that if I have over 1,000 modules on my system, I will be doing a lot time-consuming searching. Am I wrong to look at it this way?

Thank you for explaining the algorithm you were thinking of. It's a bit off ;-)

use File::Spec;

    my $mod_path;
    foreach my $i (@INC)
    {
        if ( -f File::Spec->catfile($i, 'Some/Module.pm') )
        {
            $mod_path = $i;
            last;
        }
    }
    if ($mod_path) {
        # Some::Module is installed here.
    } else {
        # Some::Module is not installed anywhere.
    }
[download]

The number of tests is directly proportional to the number of paths in @INC (that is, O(scalar @INC)), and is completely independant of the number of other modules that may be installed in any include path.