http://qs321.pair.com?node_id=1210479


in reply to Help Changing use into require/import

UPDATE: This *could* be bad advise, see the reply node at Re^2: Help Changing use into require/import by stevieb.

The way I do this, certainly there are other ways:

my $HAVE_Capture_Tiny = 0; eval "use Capture::Tiny qw(capture)"; if ( !$@ ) { $HAVE_Capture_Tiny = 1; } ... if ( $HAVE_Capture_Tiny ) { my $c = Capture::Tiny->new( ... ); } else { ## fallback if not have Capture::Tiny }

UPDATE 2: Based on the nodes below, my new way of doing this:

use strict; use warnings; # Instead of: # # use Module::Name 1.00 qw(:subs); # # do this: my $HAVE_Module_Name; BEGIN { $HAVE_Module_Name = eval { require Module::Name; Module::Name->VERSION( 1.00 ); Module::Name->import( qw ( :subs ) ); 1; }; } if ($HAVE_Module_Name) { print "Module::Name = $Module::Name::VERSION\n"; } else { print "Module::Name = [NOT INSTALLED]\n"; }

Replies are listed 'Best First'.
Re^2: Help Changing use into require/import
by stevieb (Canon) on Mar 07, 2018 at 21:10 UTC

    Not putting down the way you do it, but just checking $@, particularly without checking what's in it could be problematic in some cases (ie. the variable could potentially be set during this check, unrelated to your eval(), which would technically trigger a false-positive failure). Any eval error happening in the require could also fail with an error, but your eval will reset this var to undef as soon as it starts. Here's a very similar way that does kind of the same thing, but checks the state of the eval, not whether there's an error. It also uses block eval as opposed to string eval:

    BEGIN { # look for JSON::XS, and if not available, fall # back to JSON::PP to avoid requiring non-core modules my $json_ok = eval { require JSON::XS; JSON::XS->import; 1; }; if (! $json_ok){ require JSON::PP; JSON::PP->import; } }

    What happens there is that if any of the lines prior to the 1; in the eval fail, the eval block will return false (undef to be specific). If all expressions within the eval succeed, the $json_ok variable will be true, and we can proceed confidently.

    See a number of issues with eval in the Try::Tiny documentation (which could be, after all, a different approach to the OP's problem. To be honest, I've never used said distribution that I recall).

      Good point.

      My goal in this was to be able to use more complicated "use" statements like:

      use My::Module 0.04 qw( :sub1 :sub2 );

      I just can't seem to get those to work with the require / import way so needed a way to "use", which didn't blow up if the module wasn't found. I'm sure I didn't "invent" this; rather, Google-d, found something and used it without understanding the implications you pointed out. And I've just been "using" it ever since.

      I wonder if "undef $@" before the 'eval' would help ensure any error ending up in $@ is coming from the eval?

        > I wonder if "undef $@" before the eval would help ensure any error ending up in $@ is coming from the eval?

        Better using local in such case (I think..)

        { local $@; eval "use Capture::Tiny qw(capture)"; if ( !$@ ) { $HAVE_Capture_Tiny = 1; } }

        See also eval, DESTROY, die and $@ - educational couple of hours

        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

        It's pretty rare that the issues I pointed out will crop up, but I thought I'd raise them here just in case.

        I hate to call it a "race condition" (because technically it isn't), but it is something to be aware of, and I found out about the 1; trick after spending hours sorting out why some of my tests were failing (a previous call to eval's error was being reset, causing all sorts of grief later on).

        Only wanted to state it here as although I don't believe it's an official "best practice" or "perl idiom", it really ought to be :)

        Besides, I explicitly don't like string eval, so avoid it wherever feasible/possible.

Re^2: Help Changing use into require/import
by computergeek (Novice) on Mar 07, 2018 at 23:08 UTC

    I tried your code and get this error: Can't locate object method "new" via package "Capture::Tiny" at ./foo.pl line 40. I am not sure if this means I am dead in the water or if there is another way. When I was doing research on import it appears the module writer is the one who implements and it is not a generic perl feature.

      Can't locate object method "new" via package "Capture::Tiny" at ./foo.pl line 40

      Capture::Tiny doesn't have a new() method, and Capture::Tiny->new() will therefore fail irrespective of how you loaded the module.

      Cheers,
      Rob

        So is there a way to load it dynamically?

      That's just my quick example. There is no new() constructor in Capture::Tiny, I was just throwing down a quick template and overlooked that. That'd be where you use the capture() sub you imported.

        I have read a "use" does a require and import but when I try to do these explicitly it just does not seem to work. You say that capture tiny has no new constructor and I do not know how to translate that to what needs to be done to load the module dynamically. I have tried to move on to ipc::run but am having similar difficulties so I for sure do not have the knowledge to do what needs to be done to load these dynamically or they cannot be loaded dynamically and again if they cannot, I don't know how to tell for sure that it is an impossible task which takes me back to the original question of I am looking to learn generically how to look at a module and tell what is required for a module and adapt a require/import combo that will work based on the way the module was written. I am in essence asking not to give me the fish although that would be appreciated but also teach me to fish so I can do this from now on.