in reply to Re: Use 'use' in foreach
in thread Use 'use' in foreach

Thanks for the long answere. I have one array with all non core modules I need for the execution of the script. If eval "use $_" fails, the module gets pushed into the second array — @NotInstalledModules. The script then installs all @NotInstalledModules via cpanm. eval "use $_" was the last missing part of the puzzle after the installation.

Replies are listed 'Best First'.
Re^3: Use 'use' in foreach
by Corion (Patriarch) on Jul 20, 2017 at 09:03 UTC

    Personally, I would look at splitting the script into two scripts and using the standard Perl installation approach, but I understand if you want to make things as easy as possible for the user.

    The standard installation approach would be to list all the modules your program needs in Makefile.PL and then just use cpanm --installdeps . to install all the modules your script needs automatically.

    This has the drawback that you need a second file with your script, but the huge advantage that your installation process now also works with cpan and almost all other, and future installation processes for Perl stuff.

    A very simplicistic Makefile.PL would look like the following:

    #!perl -w use ExtUtils::MakeMaker; our %module = ( NAME => 'myscript, AUTHOR => q{zidi <zidi@example.com>}, PREREQ_PM => { 'strict' => 0, ... }, ); if(! caller()) { WriteMakefile( %module ); }; 1;
      Thanks for taking your time. That's actually how I install my @NotInstalledDependencies after the user agrees to. The only difference is that I create the cpanfile, execute it and delete it within my script. I am new to Perl and in this project I want to do as much as possible within one workflow-script and learn by doing.

        The cpanfile is somewhat more specific and basically only supported by cpanm and not the other toolchain elements. But other than that, your approach sounds fine.

        Of course, ExtUtils::MakeMaker and cpanm also implement the logic of finding whether a module is installed or not, so you could simply always write out the complete list of modules that your script needs and have them deal with the problem. But that wouldn't be fun and educational...