in reply to Re^3: Using Cartons to automate module installs
in thread Using Cartons to automate module installs

So, yay, that I'm getting results, but I don't quite understand the line of code I'm using to get them. Can you "talk through" what happens on this line, in particular, how the %s's get populated?
scandeps.pl -R *.pl | perl -ne 'printf qq{requires "%s", "%s";\n}, eva +l'

Sure:

  1. The output of scandeps.pl looks something like:
    'Module::Name' => 'version', 'Module::Other' => 'version', ...
  2. The output of scandeps.pl is fed into perl, which due to the -n switch reads its input line-by-line, setting $_ to each line.
  3. eval evaluates $_ when given no arguments, so it'll evaluate each line, a string such as "'Module::Name' => 'version'", as Perl code.
  4. The =>, aka the "fat comma", is just a Comma Operator in disguise, so each line of input evaluates to a list of two values, the module name and its version.
  5. Assuming no syntax errors, eval returns these two values, and they are used as the two arguments to the printf.
It seems to me that it invites disaster to compose a cpanfile by hand, never mind the tedium.

Personally, I don't think so - note that the output of scandeps.pl can sometimes be a lot more verbose than it needs to be. I think it's better to get an understanding of what the module dependency tree looks like instead of blindly relying on the tool - I usually try to keep track of which CPAN dependencies I add to my scripts, and I only use scandeps.pl to get hints whether I may have missed something. Note that in the output you showed, all the the ExtUtils::MM_* modules can probably be omitted, and also ExtUtils::MakeMaker and File::Temp are core modules, meaning that unless your script requires a certain new version of them, they usually don't need to be listed.