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.
The realisation that author's won't upgrade their modules to pick up improvments to M:I should have been something I understood earlier.
I knew you'd eventually come around!
Re:Good!
Alias on 2008-03-18T07:48:55
I think this whole debate serves as a useful lesson beyond this single point though.
The point I understood early that I think you took a while to realize is that you can't educate the users. You can't expect an install to fail and have the user learn about Module::Build and install it. We saw the same problem with PREFIX.
What I misunderstood is that you can't educate the authors either. I held authors to a higher standard than users and figured that we could at least educate this more limited audience. And I was wrong.
The underlying point here is that you can't thoroughly educate ANYBODY, and thus education can never be the solution to a technical problem. Humans will always exist on a gradient from naive to expert.
At a fundamental level, technological problems can only be solved robustly and should only be solved by technological answers. Anything that relies on education is insufficient and should only be employed as a temporary workaround.
Re:Good!
chromatic on 2008-03-18T18:01:04
The point I understood early that I think you took a while to realize is that you can't educate the users.I reject the idea that users are born knowing how to configure and run CPAN to install a distribution, but somehow that magical education stops when they run into problems. If that were true, I wouldn't have a job at a media company dedicated to the proposition that we can publish information for users to educate themselves.
Re:Good!
Alias on 2008-03-19T02:01:10
Let me rephrase.
You can educate some of the users some of the time, but you can't educate all of the users all of the time.
And since our goals should be to find complete solutions, education doesn't really play much of a role in that process, because it can't be a complete solution.Re:Good!
Aristotle on 2008-03-19T03:26:50
Sure, but that does not refute Adam’s statement. You can’t educate users, except when they are already receptive.
“The power of instruction is seldom of much efficacy, except in those happy dispositions where it is almost superfluous.” —Edward Gibbon
Re:Good!
chromatic on 2008-03-19T05:34:29
You can’t educate users, except when they are already receptive.I'm all for detecting failure conditions, recovering gracefully when possible, and giving clear and concise debugging instructions otherwise. Programmers should do all of those things.
In the case of installing modules from the CPAN, users have already received some degree of instruction already. We ought to assume that we're not dealing with people who've accidentally configured the CPAN shell and somehow started installing a module. Someone walked them through it, or they read directions somewhere.
I agree that occasionally we'll run into people who've copied and pasted instructions from somewhere without reading or understanding them, but we'll never fix that, and I don't see how it's worth anyone's time to try.
Re:Good!
slanning on 2008-03-19T09:59:23
I'm not sure I agree with you that users have received some instructions. Anyway, I have a story, though maybe it's not even relevant.
At work, my office is along a busy hallway. There's a drinking fountain there, and it dispenses plastic cups. Beside the fountain there's a plastic-cup receptacle for recycling the plastic cups, and there is also a trash can. The plastic-cup receptable has four slots, and the slots are the same size as the cups. It's a clever system, designed so that the cups are neatly stacked instead of strewn randomly, so that the cups are easier to recuperate.
However, what happens is that people always throw their cups into the trash can.
It's not that these people are stupid or uneducated or malign. And in fact there's a drawing on the plastic-cup receptacle showing a cup with an arrow, indicating that "cups go in here", so in some sense there's even an attempt to educate them. But that doesn't matter... They are just passing by, happen to be thirsty and spot a water fountain. Why should they have to solve a four-small-slots puzzle just to dispose of an empty plastic cup when there is a one-large-slot trash can there?
At first, I just picked the cups out of the trash can and put them into the receptacle myself. Day after day. Then I tried rearranging the receptacle and trash can, making sure the receptacle was directly beneath the cups, orienting the drawing on the receptacle so that it was clearly visible to fountain users. Didn't matter, cups continued to be put into the trash can.
Eventually I hit on the idea of putting the trash can against the opposite wall (2 meters away). Now when fountain users are done with their cup, they look down and only see the receptacle, the trashcan option has been taken out of the picture altogether. They still don't really have to think about it, though, just now it's a matter of either throwing the cup on the floor (and who would do that!?) or putting it in one of the holes.
I guess I agree with Alias that it's not about education, and with Aristotle that one has to be receptive to being educated anyway. I also think we tend to misjudge how users will use a system and to be somewhat arrogant/self-centered in thinking that our system is so important that users will want to take the time to learn it, when there might be other, simpler options ("hey look, Ruby does what I wanted!").
Re:Good!
chromatic on 2008-03-19T18:29:27
I'm not sure I agree with you that users have received some instructions.How in the world else would a user find himself in a situation where he has started to install a distribution from a CPAN shell and that module requires an updated version of a configuration/installation distribution?
A user must deliberately start the CPAN shell, configure the CPAN shell (unless someone has already configured it), and deliberately type the invocation to install a distribution.
How does a user know to do this unless he has learned it?
(I admit that there's a case where an automated installer attempts to install CPAN distributions, but when software attempts to hide the details of an installation from the users, it's the software's responsibility to detect resolvable failure conditions such as this one and resolve it. This is not a case where user education is necessary.)
Re:Good!
Alias on 2008-03-20T02:46:38
The maximum we can assume the user understands is how to invoke the CPAN shell, and how to type "install Module".
Hell, in Strawberry Perl I take it one step beyond that.
I ship a cpan client that is already pre-configured to sensible defaults, and I add a start menu icon for "CPAN Client".
So whatever, they can invoke an install. That's a level of education I can accept.
Note, however, that this DOESN'T require any Perl knowledge yet.
HOWEVER, when an installation fails and somewhere in the middle of 1000 lines of output spew is a message that says "Can't load Module::Build.pm" followed by 500 lines of random spurious errors, how on earth is someone meant to know what that means.
They don't know how to diagnose the problem out of all that error spew. Hell, their scrollbacks may not even be large enough to show it.
Re:Good!
chromatic on 2008-03-20T06:24:18
HOWEVER, when an installation fails and somewhere in the middle of 1000 lines of output spew is a message that says "Can't load Module::Build.pm" followed by 500 lines of random spurious errors, how on earth is someone meant to know what that means.I agree. That needs fixing, preferably in an automated way.
The maximum we can assume the user understands is how to invoke the CPAN shell, and how to type "install Module".There's the point at which the documentation needs to explain how to fix the common failures./p.
Re:Just to be clear
Alias on 2008-03-18T10:05:06
I'm certainly saying you SHOULDN'T use it, since it spawns a sub-CPAN client, which may well explode.
If you have a simple module then you'd be far better off generating a compatibility Makefile.PL rather than a pass-through.
The pass-through functionality would be best off being deprecated.Re:Just to be clear
btilly on 2008-03-18T19:46:31
Huh. I just looked at one of my Build.PL scripts.
use Module::Build;
Module::Build->new(
module_name => "Text::xSV",
license => 'perl',
create_makefile_pl => 'traditional',
)->create_build_script;
The Makefile.PL doesn't refer to Module::Build in any way.
That isn't what you're deprecating, right?Re:Just to be clear
Alias on 2008-03-19T02:02:09
Nope. "traditional" is quite sane.
It's the other one, "passthrough" I think, that's conceptually broken in the same way.Re:Just to be clear
Aristotle on 2008-03-19T03:34:40
That is so that people can install the module any way they please
If you were actually using pass-through mode, that would not be the case. The
Makefile.PLthat is generated in that mode invokesBuild.PLto do the work, incidentally offering to recursively install Module::Build if necessary. Therefore such distributions cannot be installed without Module::Build.In contrast, the traditional mode you are in fact using generates a regular
Makefile.PLthat invokes ExtUtils::MakeMaker as per usual, so does indeed allow the user the freedom to choose their preferred method.The module in which this is documented is Module::Build::Compat.
and know that all the dependencies will be installed for me. I suppose I could switch to using pip, or something, but it would be more awkward. Of course, this is again using AutoInstall as a top-level CPAN(PLUS)? invocation: invoking CPAN recursively is always wrong.$perl Makefile.PL
make
make test
Re:auto_install
Aristotle on 2008-03-19T03:37:47
Just replace that incantation with a single “
cpan” inside the unpacked tarball’s directory.. Re:auto_install
mauzo on 2008-03-19T04:09:42
Presumably I could fix this by upgrading CPAN (this is 1.8802), but the whole point is that with M::I as it stands the above will work on a clean install of perl, so I can see what a module is going to do in that environment.Warning: Cannot install., don't know what it is.
Try the command
i/./
to find objects with matching identifiers.Also, what I gave doesn't go any further than
make test. I specifically don't want this module installed (it doesn't work yet), I just want to run the tests to see what needs fixing. Presumablycpan -twould do that (with a sufficiently recent CPAN)?.
