App::Midgen what is it?
This is an aid to present a packages module requirements by scanning the package, then displaying in a familiar format with the current version number from CPAN.
This started out as a way of generating the core for a Module::Install::DSL Makefile.PL, why DSL because it's nice and clean, so now you can generate the contents and check when you want, yes it's another PPI powered app.
All output goes to STDOUT, so you can use it as you see fit.
CPAN Version Number Displayed
- NN.nnnnnn we got the current version number from CPAN (numify)
- 'undef' no version number returned by CPAN
- 'core' indicates the module is a perl core module
- '!cpan' must be local, one of yours. Not in CPAN, Not in core.
Food for thought, if we update our Modules, don't we want our users to use the current version, so should we not by default do the same with others Modules. Thus we always show the current version number, regardless.
We also display some other info to complement the modules we have found.
For more info and sample output see wiki
Change to the root of the package you want to scan and run
midgen [options]
--help --output --core --verbose --parent --mojo --noisy_children --twins --zero --debug
I am primarily a dyslexic technologist, with a history in e-mail and biometrics among other things, who just likes to ferret around until I find what I am looking for, then latch on like a Jack Russell, until it works or I understand why not. 
My P5U::Command::Deps is similar. (Sample usage and output.)
One feature P5U::Command::Deps does not currently do is scan for a list of package names that the codebase provides, and excludes them from dependencies. For example, in the sample usage above, it is scanning the Path-Iterator-Rule codebase, and it lists Path::Iterator::Rule as a test_requires dependency. Strictly speaking true, but not helpful. This should hopefully be solved in a future release soonish (because it bugs me!).
Why did you not use previous art, like that used in Dist::Zilla?
https://metacpan.org/module/Perl::PrereqScanner
Do we really need another implementation that will require time to work out all the kinks and edge cases, instead of improving existing ones?
Toby this is interesting, because when I run midgen against Path::Iterator::Rule I get https://gist.github.com/kevindawson/5135322 which shows us some differences.
1, midgen did not find 'warnings::register'
2, p5u indicates :Exporter
this is of great help to me, many thanks
Mithaldu, I was unaware that Perl::PrereqScanner was capable of producing output in a format that I could just copy in to a Makefile.PL using Module::Install::DSL format with current version numbers shown.
Thanks for the heads-up.
"Exporter" should really be a test_requires dep, not a runtime dep, but current the current heuristic for determining which is which is rather simplistic (
/\.t$/).Hi Toby,
I found answer to midgen did not find 'warnings::register', midgen was just treating it as a noisy child, it was me having not met this before who got confused.
sorry
If all you wanted is a different output format, wouldn't adding that to Perl::PrereqScanner have been easier? (I wanted a cpanm-compatible format, so -- https://github.com/rjbs/perl-prereqscanner/pull/9 -- I added it.
A note on your line in italics.. I think you should list all the versions you last tested with (in each release). I often come across distributions with outdated dependencies because, I assume, later releases didn't update the dep versions.
I'm going to hack on a way to test releases against the actual dependencies they list, at the qa hackathon.. so expect cpan testers reports :)