When I took over maintainership of Module::Install, my goal was to take the magic functionality created by others and add a level of reliability to it so that it could be used safely.
I've fixed various features, tried to improve some of the magic to work better, and generally puttered around writing docs and bug fixing.
After several years of this, and looking at the direction that the future of the CPAN toolchain is heading in (and having learned many lessons from this whole process) I think I'm confident enough now to draw a line through some parts of M:I, judge them as fundamentally flawed, and remove the functionality.
So on top of the normal bug fixes and refactoring, Module::Install deprecates some major features that simply don't work.
Firstly, I'm no longer going to support "Build.PL" mode.
The original idea was that the magic Module::Install syntactic sugar would support BOTH the MakeMaker back end, and the Module::Build back-end.
It would just detect the way you launched it, and hand off appropriately either way.
While detecting Makefile.PL vs Build.PL invocation works just fine, the idea that every single feature will need to be implemented twice just isn't holding up.
It's a maintenance nightmare, it's never worked properly, it confuses downstream packagers, and it is fundamentally flawed. To implement it properly, I'd really need to bundle the entire copy of Module::Build with every release, and that's evil as hell.
So I'm dropping support for it.
Secondly, I'm finally dropping support the infamous auto_install.
This has caused huge amounts of trouble for myself, CPAN.pm and CPANPLUS.pm, with confusion and failure endemic to the feature.
The realisation that author's won't upgrade their modules to pick up improvments to M:I should have been something I understood earlier. This means that old code hangs around for a long time, and old auto_install logic was indeed evil and ugly.
After years of playing around by both me and Module::Build's pass-through mode, I am now convinced there are no remaining credible scenarios in which you would ever want to recursively spawn a second CPAN client. You report what you need upwards, and let the prime CPAN client deliver it. That's it.
There are a few groups, most noticeably Catalyst, who use auto_install as their top-level CPAN client, and this change will break that process.
I apologize for this, but the pain is necessary to restore the integrity of Module::Install within the overall CPAN toolchain.
I'm talking to Matt Trout about alternative solutions for Catalyst, which may involve the restoration of some of the same code under a standalone plugin, or some other way which rigourously ensures that a CPAN client can never be spawned from inside an existing CPAN client.
If you have functionality which critically depended on auto_install, please mail me and we can discuss alternative solutions for your problem.
In other news, this release of Module::Install is the first to formally support the configure_requires command. It was previously a null stub.
If you have existing Makefile.PL that use configure_requires, they will now start to work.
To spur adoption of configure_requires in CPAN clients, I've added code to always add a configure_requires entry for the version of MakeMaker installed on the author's computer.
This will be removed in future if it becomes troublesome.