Testing for a module's presence

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Testing for a module's presence by broquaint (Abbot) on Feb 06, 2005 at 04:36 UTC
You could use `Module::Locate` for the job e.g `use Module::Locate 'locate'; print "Couldn't find Some::Module" unless locate 'Some::Module';` [download] This code will return the path to the module if it is on the system or false if not. Also it doesn't load the module it just checks for its presence in the same manner that perl's `require` does. HTH `_________ broquaint`	[reply] [d/l]
CPAN knows how by adamk (Chaplain) on Feb 06, 2005 at 06:06 UTC
Or Class::Inspector... `use Class::Inspector; if ( Class::Inspector->installed($module) ) { ... }` [download]	[reply] [d/l]
Re: Testing for a module's presence by rlb3 (Deacon) on Feb 06, 2005 at 02:44 UTC
Hello, I think you would have to do something like: `eval { require Some::Module; }; if ($@) { print "Can't find Some::Module\n"; }` [download] When you say "use", things happen at compile time and would happen before the eval so, the error would not get trapped. rlb3	[reply] [d/l]
Re^2: Testing for a module's presence by sandfly (Beadle) on Feb 11, 2005 at 23:09 UTC
"require" also better because it doesn't call import(). The module code still gets executed though. Typically, "require"d modules just create subs in their own package, but a badly-behaved module could in principle mess up any namespace. If you want to "use" a module at runtime, you can eval a quoted string: `eval "use $mymodule";<br>print $@ if $@;`	[reply] [d/l]
Re: Testing for a module's presence by dimar (Curate) on Feb 06, 2005 at 03:21 UTC
That's funny, I was just doing a little light reading on Checking to see if a particular Module is installed when your question, Testing for a module's presence appeared on Newest Nodes. Deja vu. If you haven't already, you might want to try Super Search for additional discussions on this from the past.	[reply]
Re^2: Testing for a module's presence by Anonymous Monk on Feb 06, 2005 at 05:45 UTC
I used super search and googled thepen. The problem with such a search is the keywords: I used "test" and not "check," and "presence" or "exists" and not "installed". Perhaps the problem is twofold: Perlmonks doesn't group questions in SOPW. Everything is thrown into one big fat section. This makes searching more difficult. The other problem is the English language. There are so many synonyms like "test" and "check".	[reply]
Re^3: Testing for a module's presence by dimar (Curate) on Feb 06, 2005 at 06:40 UTC
I used super search and googled thepen. The problem with such a search is the keywords: I used "test" and not "check," and "presence" or "exists" and not "installed". ... which is why I said "If you haven't already" tried supersearch ... just like you, I noticed the keyword disparity and I did not automatically assume you had overlooked supersearch. As far as your observations on SOPW organization and English synonyms, my initial response to you was specifically intended to address those (percieved) problems. How? Well you see, now there is a new node that contains all of the different keywords in one place. It patches the 'keyword gap'. That's how humans like you and me can help make SuperSearch and Google even better. Of course there are many other synonyms out there that remain "unconnected", but that's the name of the game ... Wash, Rinse, Repeat.	[reply]
Re: Testing for a module's presence by vek (Prior) on Feb 06, 2005 at 06:07 UTC
I usually do something like this early on in my code: `my $HAVE_MODULE = eval 'require Some::Module; 1' ? 1 : 0;` [download] I can then react accordingly later on: `if ($HAVE_MODULE) { do_stuff(); } else { do_something_else(); }` [download] -- vek --	[reply] [d/l] [select]
Re: Testing for a module's presence by itub (Priest) on Feb 06, 2005 at 04:43 UTC
I'm curious, why is traversing @INC out of the question? This would be done implicitly anyway regardless of the method you choose, whether by perl itself, a third-party module, or your own code.	[reply]
Re: Testing for a module's presence by sgifford (Prior) on Feb 06, 2005 at 04:04 UTC
If you don't want to affect your running program at all and speed isn't critical, just fire up a new copy of perl: `#!/usr/bin/perl use warnings; use strict; use POSIX qw(_exit); foreach my $mod (qw(CPAN No::Such IO::Socket Not::Installed)) { printf "%20s: %-3s\n",$mod,is_module_installed($mod)?"Yes":"No"; }` [download] `sub is_module_installed { my($mod)=@_; return (system("perl -M$mod -e 1 2>/dev/null") == 0); }` [download] `sub is_module_installed { my($mod)=@_; defined(my $pid = fork) or die "Fork error: $!\n"; if ($pid) { # Parent waitpid $pid,0; return $? == 0; } else { # Child close(STDERR); eval "use $mod;"; _exit($@?1:0); } }` [download] You could make it a little faster using`fork`, to avoid firing up a new interpreter from scratch. Updated: Tanktalus points out that the copy of perl that `system('perl ...')` will start may not be the same as the running one; `fork` will use the currently running interpreter in a new process, so avoids that problem. It should also be a bit faster. Updated: Fixed Tanktalus' name in previous update. :) Also addressed his concerns about `atexit` using `POSIX::_exit`.	[reply] [d/l] [select]
Re^2: Testing for a module's presence by Tanktalus (Canon) on Feb 06, 2005 at 05:26 UTC
We take some risks here either way. "perl" may not be the currently running perl (here, for example, "perl" is the stock perl that comes with the Linux distro I'm running - 5.8.0, while "perl5.8" is a symlink to the latest perl5.8 binary I've compiled - 5.8.5), while using $^X may also not be quite useful (since the currently executing code may be running in an embedded perl rather than a standalone perl executable - isn't that how mod_perl works?). Personally, I'd just use require as others have pointed out. And if you don't want to use the extra memory, you can delete it from %INC afterwards - perl will then be able to re-use that memory. It does mean that you'll get a negative when the module exists and is found, but doesn't compile, but that's probably the same thing as not being there, really.	[reply]
Re^3: Testing for a module's presence by sgifford (Prior) on Feb 06, 2005 at 05:59 UTC
Will deleting from `%INC` really free much memory? For example, will it free storage space for strings and subs created by the module when it's `require`d? Or does it just free the storage for the filename itself?	[reply] [d/l] [select]
Re^4: Testing for a module's presence by Tanktalus (Canon) on Feb 06, 2005 at 06:05 UTC
Re^3: Testing for a module's presence by Anonymous Monk on Feb 06, 2005 at 05:34 UTC
And if you don't want to use the extra memory, you can delete it from %INC afterwards - perl will then be able to re-use that memory. Memory is an issue! Can you show me how to delete it from %INC after I required the module in an eval? Thanks.	[reply]
Re^4: Testing for a module's presence by Tanktalus (Canon) on Feb 06, 2005 at 05:41 UTC
Re^5: Testing for a module's presence by Anonymous Monk on Feb 06, 2005 at 05:54 UTC
Some notes below your chosen depth have not been shown here
Re^2: Testing for a module's presence by Tanktalus (Canon) on Feb 07, 2005 at 02:00 UTC
(Ignoring the typo of missing the 'n' in my alias ;->) While fork can work great on Unix, it's not quite so great on other platforms. EMX on OS/2 (and maybe Win32) handles fork - but it's not really faster. I doubt ActiveState or Cygwin perls handle it (if either do, it'll be Cygwin). So you've simply hit another gotcha: cross-platform compatability. (Traversing @INC and using File::Spec is fast, tight on memory, and completely cross-platform!) Even on Unix, fork may not be that great. Imagine an embedded perl. The main process (the embedder) has some cleanup in an atexit() in C. That cleanup may include committing or rolling back transactions, deleting temporary files that were in use, or other such behaviour. When you fork, and then the child exits, the atexit handler kicks in and does something like this - and now the parent process is going to be in a wierd place that is going to be really painful to debug. Especially if this ends up on a user's machine and the user imported your module. The C developer has no idea what is causing it, the perl user has no idea, and you're not really involved. Dangerous! Fork is a dangerous tool - although it can be useful, you have to be really really careful of when you use it, and how you use it. Let's just stick to searching @INC. It's fewer lines of code, too ;-}	[reply]
Re^3: Testing for a module's presence by sgifford (Prior) on Feb 07, 2005 at 04:45 UTC
The thing I don't like about searching `@INC` is that it's re-implementing a part of Perl based on how it works right now. A future version of Perl could use a different scheme for locating libraries. For example, it could add a new type of arch directory, hash the directories to avoid too many modules in the same directory, add a new `.pmz` type for compressed modules on disk-poor systems, or load code across the network. A user could even provide their own copy of the `lib` module and/or the `require` function to implement those sorts of things right now. In the face of possible changes to the module search algorithm, actually asking Perl to find the library and say whether it worked or not will always work, while re-implementing the library search yourself will only work for as long as nothing changes. Using a module designed to do this, as others have suggested here, is a good compromise. As for the cross-platform concerns, I have used `fork` on ActiveState Windows; it seems like a lot would break without a working copy of this function. And `POSIX::_exit` seems to avoid your other concerns. Also, to clarify, I don't think using `fork` will be particularly fast; just faster than using `system`, which was my original proposal.	[reply] [d/l] [select]
Re^4: Testing for a module's presence by nothingmuch (Priest) on Feb 10, 2005 at 10:12 UTC
Re^3: Testing for a module's presence by Anonymous Monk on Feb 08, 2005 at 05:13 UTC
As my sister comment mentions, ActiveState has some support for fork(). In my experience, only a few obscure things don't work. But: `% perldoc perlfork ... AUTHOR Support for concurrent interpreters and the fork() emulation wa +s implemented by ActiveState, with funding from Microsoft Corporation +. This document is authored and maintained by Gurusamy Sarathy <. +.@activestate.com>. ...` [download]	[reply] [d/l]
Re: Testing for a module's presence by jpk236 (Monk) on Feb 06, 2005 at 02:42 UTC
if you're running FreeBSD, or a similar operating system, you could do something as follows: `#>pkg_info \| grep -i "MODULE"` [download] Justin	[reply] [d/l]
Re^2: Testing for a module's presence by DrHyde (Prior) on Feb 07, 2005 at 10:53 UTC
This assumes that you only install modules using your OSes packaging system.	[reply]
Re^3: Testing for a module's presence by jpk236 (Monk) on Feb 07, 2005 at 14:54 UTC
Why wouldn't you want to? That's the beauty of FreeBSD. Justin	[reply]
Re^4: Testing for a module's presence by ehdonhon (Curate) on Feb 07, 2005 at 19:12 UTC
Re^5: Testing for a module's presence by jpk236 (Monk) on Feb 07, 2005 at 20:24 UTC
Re^4: Testing for a module's presence by sth (Priest) on Feb 07, 2005 at 20:27 UTC
Re: Testing for a module's presence by DrHyde (Prior) on Feb 07, 2005 at 10:52 UTC
If you just want to know whether it exists you have little choice but to grovel over `@INC`. If you try to `eval "use Some::Module"` then the module will be loaded and any side-effects it has (such as exporting) will happen. I suppose if you were feeling particularly crazy you could try something like this ... `print 'the module exists' if(!system("perl -MSome::Module -e exit"));` [download] but if I saw code like that in production I'm afraid I'd have to shoot you.	[reply] [d/l] [select]
Re: Testing for a module's presence by ehdonhon (Curate) on Feb 07, 2005 at 19:28 UTC
One way to find out if and where a module is installed, assuming it is a CPAN module, and not something you have written yourself is to use CPAN.pm: `perl -MCPAN -MData::Dumper -e 'print Dumper( CPAN::Shell->expand( "Module", "Test::More" )->inst_file )'` That will return the file location of the module if it is installed, and nothing if it is not. I note that in your question you specifically mention you do not want to use the module. However, you might want to find a way around that requirement. The problem is that just testing for existence of the .pm file is not always sufficient to know if everything has been installed. It is also not sufficient if you need to know that the file compiles clean.	[reply] [d/l]


We don't bite newbies here... much
	PerlMonks