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.
Re:Noooooooooo
jesse on 2008-03-19T05:03:45
To clarify, it is very frequently the case that users are installing things like Jifty, Jifty applications, RT plugins and the like from the command line, not from within a CPAN process.
Disabling auto_install if the user is already inside CPAN or CPANPLUS makes some sense, but hobbling users installing applications or modules directly is a really bad plan.Re:Noooooooooo
Alias on 2008-03-19T05:42:52
Matt reported that there were a few other things that removing auto_install broke as well (feature() for one) plus it looks to be harder to rewrite it than I initially thought, so I've already (as of a few hours ago) released a 0.70 which rolls back the auto_install deprecation (but keeps the other changes).
This is basically to give him/you/anyone-else some breathing room to get the replacement code written (tentatively to be written in Module::Install::InstallDeps and accessible by "make installdeps").
Any comments/help welcome, but ultimately the actual command auto_install is absolutely going and if you want the other thing you change auto_install to make_installdeps; or something like that.
Re:Noooooooooo
jesse on 2008-03-19T05:47:33
What's the problem with logic of the form:
"if you're running under a CPAN/CPANPLUS process, disable auto_install, but otherwise let it run"?
Is there a reason the name for the option to automatically install prereqs needs to get changed and break Makefile.PL backwards compatibility?
It feels sort of gratuitous to force the name change and I don't quite understand what forcing the name change wins if you're replacing the implementation with something that voids the pitfalls.Re:Noooooooooo
Alias on 2008-03-20T01:15:44
The logic is just fine.
The IMPLEMENTATION of "if you're running under a CPAN/CPANPLUS process" turns out to be impossible to implement robustly, despite years of trying.
So while it's ok to LAUNCH a CPAN shell from a Makefile.PL in principle, it's not ok to try and automatically detect which way you should go.
The reason to change the command name is to separate out the intent of the authors who want the ABILITY to use Makefile.PL as a top-level installer vs people that want to use auto_install to do inline install within a larger CPAN install.
Re:Noooooooooo
srezic on 2008-03-19T13:37:57
Are you aware of the presence ofcpan(that is, cpan dot, called from the command line)?. neat
jesse on 2008-03-19T17:16:59
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, either:/ I'm not yet sure if this will solve my specific problem, though it may. But I'm known to have a big problem with backwards incompatible API breakage in CPAN modules which have been widely used or publicly available for a long time.
Re:Noooooooooo
brian_d_foy on 2008-03-19T20:52:16
Heh, I've never thought ofcpan. It's something that I'll have to add to the documentation.. :) Re:Noooooooooo
srezic on 2008-03-19T21:10:18
Yes, I am about to change the lengthy(and also mentioning "nmake") with justperl Makefile.PL
make
make test
make installin my distribution READMEs.cpan. Re:Noooooooooo
brian_d_foy on 2008-03-19T21:20:17
Well, I wouldn't replace it, but put it first and then label everything else "the hard way":)
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), they still need instructions to do it the old way.Re:Noooooooooo
Alias on 2008-03-20T01:27:21
The old way (with auto_install at least) still needs to invoke CPAN.pm...
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.
(From that wikipedia place, but I swear I didn't edit it just to make a point. The emphasis is mine, though)In computer software standards and documentation, the term deprecation is applied to software features that are superseded and should be avoided. Although deprecated features remain in the current version, their use may raise warning messages recommending alternate practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated—rather than being removed—in order to provide backward compatibility and give programmers using the feature time to bring their code into compliance with the new standard.
Adam's gone and backed out the removal of the feature, so this is temporarily a non-issue. But when you deprecate an API, it's _supposed to keep working_ during a transition period.
If the feature does end up getting redeleted, having Module::Install just stop working if there's an auto_install directive in a Makefile.PL seems like a really bad choice that's likely to hurt the less savvy users that auto_install was there to help in the first place. If the intent is that the feature is both broken and unneeded if the end-user is following best practices, make M::I smart enough to say "Hey! The author of this Makefile.PL did something that's no longer supported. I've dealt with it for you" rather than:
sub auto_install {
die 'Module::Install::AutoInstall often breaks CPAN and has been deprecated';
}
That's the kind of thing that reenforces the unfortunate "CPAN is an unusable nightmare" meme.
Re:Deprecations should not break software.
Alias on 2008-03-20T01:26:03
In my defense, the command has been DOCUMENTED as deprecated for some time.
As Matt pointed out though, nobody reads the documentation.
Further, please let me be clear to everyone that Module::Install is NOT like other parts of the toolchain.
If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at all.
Existing modules with auto_install in them will continue to work exactly the same and don't break. This was the entire principle behind Module::Install in the first place. Whatever was installed on the author's computer at the time they packaged the module is what will be used by the end user at the time they install the module.
That is the reason I've continued to refuse to implement "use a newer version if we find it on the user's computer". Because that doesn't fit the Module::Install world view.
So this change impacts only on module authors, not module installers.
For a module author, when they upgrade Module::Install and try to run Makefile.PL, they get some sort of "auto_install has been deprecated, please see $url for more information" or some other error that directs them to the information they need, or explains the situation.
For example, if you look in the M:I source code for Module::Install::Deprecated, you can see some existing deprecation hooks for certain commands relating to C elements that were renamed a while back.
Re:Deprecations should not break software.
jesse on 2008-03-20T01:41:18
Where has the deprecation been documented?
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 all."
That's true for people installing from CPAN, but it's plenty common for people to check things out of subversion repositories or otherwise end up with a Makefile.PL that uses Module::Install and end up regenerating inc, but yes, I acknowledge that this isn't as bad as if someone gratuitously broke backwards compatibility in MakeMaker.
But yeah, call it "the feature has been removed" when that's what you mean. Deprecated means "this will be changed or removed in the future, it's time to start migrating away" not "this is already gone"
