"Can't You Just..." is a dangerous phrase, and one of those big smells. In fact, just the use of the word Just, or Simply, or Trivial, or Easy causes a fair bit of ponginess.
There's a few places that talk about "CYJ" as it's known. My first encounter with the concept was on the C2 wiki.
And I know that Andy Lester has talked about it before too.
But CYJ in an interactive discussion scenario is not the worst form. You at least have a chance to discuss.
For me, where CYJ really starts to hurt is when it starts to break Elaine's Law ("Just make it easy to fucking install stupid!").
That is, when in some form of installation system, like say debian's apt packaging environment, instead of just installing a program, the authors expect you to take additional steps before or after the install. Steps that nobody else that creates packages expects you to do.
Until recently, RT was my example of this problem. RT for all it's advantages (and Jesse really has done a great job) is/was not at all easy for non-admins to install. And it was (until recently upgraded) the only debian install I ever encountered that, after doing the apt-get install command, expected you to read through a text file and follow a "simple" 6 step additional setup and configuration process.
But that's still not quite as bad as it gets, because I can choose to just use Bugzilla on that host instead, which does fully install on an apt-get install command.
CYJ gets amplified even further again when you mix in CPAN, and the vast web of dependencies it contains. Which brings us to Module::Build.
Module::Build, regardless of how good it is, has an expectation you will "just" have installed Module::Build yourself independantly BEFORE you install anything that uses it.
Because the dependency information is generated in the Build.PL file, it doesn't help to add M:B as a dep to a M:B-using installer either.
This would be less of a problem if M:B hadn't been promoting it's use and created the current situation where hundreds of CPAN dists use Module::Build. And of course it is compounded by the Makefile.PL "compatibility" code ALSO using Module::Build without declaring the dependency.
So as it stands now, if you get a fresh Perl install, and you try to use CPAN.pm (and especially the versions that come with that fresh Perl install) to install any module that has a Module::Build Build.PL/Makefile.PL, then installation will fail.
To which the "solution" seems to be "Can't You Just... install Module::Build if you see the error, and then it won't happen again".
But it also happens for any module that uses another module that uses Module::Build.
Or in a more typical scenario, in a module that uses another module that uses a Test:: module that uses another Test:: module that uses a utility module which uses version.pm that uses Module::Build.
By the time the installer has run down 5 or 6 layers of dependencies, nobody that is not a professional Perl person is going to have any idea why their installation of Foo::Bar is failing. All they know is that they were trying to install RT or SVK or CVS Monitor or something else for their little company in bumsville Iowa and somewhere in the middle of the 300 pages of scrolling CPAN.pm output, something died.
And it's not their fault. It's our fault.
Of course, most people that use M:B aren't aware of this, because they have of course installed Module::Build themselves, and most of the CPAN Testers accumulate installs on each testing host. So a single CPAN Testers host ends up with M:B installed very early on, and it's not a problem after that.
So as one of my first PITA projects, I plan to get a CPAN Testers-compatible testing environment set up that "forgets" what it installs and starts each distribution install from the vanilla Perl install, with the originally shipped CPAN.pm.
If ANYTHING you depend upon starting from the vanilla Perl upwards all the way to your dist fails, then you fail. (although when transforming reports to the actual CPAN Testers list, we follow their rules and blame it on the last module in the chain that actually uses Module::Build)
So if there is a structural problem somewhere, it's going to show up really quickly, in the form of hundreds or thousands of failures. And the same thing should happen with things like Schwern's Test::Tester situation.
And I'm expecting to see a LOT of modules accumulating FAIL reports that currently might appear to be PASSing everywhere.