use Perl Log In
Module::Install 0.69 - The Deprecation Release
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.
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.
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re: +1 (Score:2)
Noooooooooo (Score:2)
We use it for everything we do and it's the difference between night and day for our users. (and yes, you should read
Re: (Score:2)
Disabling auto_install if the user is already inside CPAN or CPANPLUS
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
cpan .(that is, cpan dot, called from the command line)?neat (Score:2)
No, I hadn't been aware of it. As of: :/
cpan script version 1.9, CPAN.pm version 1.9205it's not documented in in the manpage, eitherI'm not yet sure if this will solve my specific problem, though it may. But I'm known to have a big problem with backwa
Re: (Score:2)
cpan .. It's something that I'll have to add to the documentation.Re: (Score:1)
Re: (Score:2)
The trick is getting people to configure CPAN.pm so cpan works correctly. If they can't get that done (say, perhaps because they are offline or behind a firewall)
Deprecations should not break software. (Score:2)
Since we don't have a decent API versioning scheme, it often feels like the right thing to do is to change the namespace when you're making a change that will nontrivially break backcompat.
Amongst my other complaints:
Deprecation does not equal deletion
Re: (Score:2)
As of 0.68, auto_install is part of the _recommended_ usage in my copy of Module/Install.pod
You say: "If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at al