dzil authordeps - There WAS a solution already!
If you've read my last post, there's a good chance you were relieved that there was finally a command to install all the missing plugins.
However, about 5 minutes (if not less) after posting my new thingamajig, Florian Ragwitz posted a reply saying "uh.. it's already been done, and a new Dist::Zilla is released with it today".
So, take even a more relieved breath because Dist::Zilla now already has it. Download it and use `dzil authordeps`!
On a technical note, it was interesting to see a different implementation of the same idea. What Florian did was to simply read the file, expand package names using Dist::Zilla::Util and print them all out. What I tried to do was perhaps more ambitious (but probably an overkill). I ran a dist building process and hooked up to the sections reading method and if the section was a plugin that didn't exist, I didn't run the section reading and marked it down. At the end I had all the sections that were plugins that didn't exist. I like Florian's method better, though. :)
Gots to do the bloggingz
Which approach is better is a question of “is the format more likely to change than the API or vice versa?”. Generally I prefer a higher-level approach like yours because it’s more likely not to miss edge cases in the format. But if there’s an official interface to the official parser then that works too.
Sort of, but not exactly.
The dist.ini parsing Dist::Zilla does includes a lot of work with Config::MVP, a lot of subclasses of it and section parsing (Dist::Zilla::MVP::Section, Dist::Zilla::MVP::RootSection, Dist::Zilla::MVP::Assembler, etc.). There is an API for expanding the strings using Dist::Zilla::Util. However, this is something my solution could use as well.
The main difference is that I hooked up to the build process (using 'around' and a small subroutine refactor patch to dzil). Instead of independently reading dist.ini, I'm letting dzil do its thing and try to catch the errors before they happen (without try/catch, of course).
I like your approach better.
Processing a dist.ini is quite complex, as you point out. Doing it right would probably have to happen at the MVP level, or above that. I simply wasn't up for that when I wrote that command, and settled for the dumb solution at a lower level, covering everything I've ever seen used in the wild, but not everything theoretically possible.
I believe The Right Solution is somewhere between our two approaches, at the config assembler level, but as your way covers various things mine doesn't, I prefer yours.
I'm certain patches to make
dzil authordepsless dumb will be gladly accepted.