"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.
Re:Elaine's Law on external libraries
Alias on 2006-01-20T15:33:59
As CPAN now gets towards 9000-10000 packages, with links to just about everything, I think the problem of external libs is showing up more and more.
The big problem is that you can't just assume what the installation process for non-Perl will be on any given platform.
For "can I run cvs" Module::Install has a can_run 'foo' command to check it, and I'd like to see that used by the debian/redhat/etc integrators to automatically add the right dependencies there.
Nobody has tried yet, but I imagine someone could also formulate a needs_lib type command which would search for a particular lib. In fact, Module::Install::Compile contains a number of these sorts of things (still undocumented, but I'm working on that).
I imagine that some enterprise Perl hacker might be able to see if there's a way to integrate EU:MM,M:B,M:I with the external system, so that on debian you had apt-file locate the package for the lib and install it and it's -dev. Or on RedHat, or Win32, the appropriate things happened there too.
It's a problem waiting for someone to have a stab at it? Wanna help?
Re:M::B Still Scares Me
Alias on 2006-01-20T15:26:20
M:B still scares me as well.
M:I saw an increase in the number of users recently, and the addition of a new project member (me) and so there's been changes to try and improve the "approachability" of M:I.
This has resulted in some bugs that were previous hidden being exposed. It also doesn't have very many unit tests yet.
But in general, M:I should be usable, and at this point I'm quite ok with it. I use it for around 60 distributions.
Yes, I'm going to have to do some upgrading of all these 60 because errors in older M:I are causing problems, but that's not so bad. At least it can be done safely, and modularly.Re:M::B Still Scares Me
chromatic on 2006-01-20T19:02:50
I still don't [willingly] use M::B to this day because all of the bug/feature/change traffic on it makes me nervous.You should look at the code for MakeMaker sometime. I stopped using it after I had to understand it enough to write tests for the thing.
I'm sorry if you (the general, non-specific pronoun) don't like my installer, but if you're going to punish me in test reports for using it, I think you (again, non-specific) ought to offer to maintain a comparable installer for me. It has to be at least as fast and simple as if I were to maintain it myself with my preferred system.
(Want more fun? Just try explaining how to write Module::Build::TestReporter with MakeMaker. "Okay, first create a new parent class called
MYfrom which MakeMaker can inherit....")Re:M::B Still Scares Me
jk2addict on 2006-01-20T21:06:01
Right. I know MM is bad. I've gotten the riot act from Schwern (http://www.nntp.perl.org/group/perl.qa/3914?show_headers=1) before for saying what I'm saying. But for me, it still holds true. As a developer, there is less risk in me staying with EU::MM, than there is in moving my stuff to M::B and having to [potentially] deal with versiou install issues, tester issues, Apache::Test::MB issues, etc.
Re:M::B "bootstrapping" mode
Alias on 2006-01-21T10:51:32
Is there any reason this couldn't be compulsory do you think?
As if I needed to get more bug reports for problems that aren't mine and I can't fix. Are you trying to make CPAN testers reports even less useful?
Re:Bleh!
Alias on 2006-01-21T10:10:16
I'm trying to make the distinction here between CPAN Testers and what this second system will be.
DESPITE how good your installer may be, if it won't install onto a default Perl install is it doing it's job of being an installer?
That's all I ask of an installer, that it installs things.
Re:Bleh!
Alias on 2006-01-21T10:54:26
Additionally, there's always things you can do to fix those sorts of DEPFAIL problem. For a start, don't use that dependency. You bought that modules problems when you bought that module.
Blame isn't the issue here. If your module breaks, it may not be your failt, but it is your responsibility to fix it.Re:Bleh!
chromatic on 2006-01-21T20:08:53
Somehow I managed to install of these evil, horrible modules that use M::B without trouble. Else why would I use them? Yet I cannot think of a single M::I installation that worked without babysitting.
AFAICT, failing a package because one of
its dependencies failed is what
ActiveState Package Build Status
has been doing for some years now.
I think this model is fine, but the ActiveState
implementation of it is poor because
their failure reports are often unclear as to
why the package failed.
To avoid annoying CPAN authors, your failure reporting must make the root cause of package failure crystal clear. Actually, even then some authors may be annoyed to see a big red FAIL next to their module due to no fault of their own.
Thanks for volunteering to create a test server to help flush out M::B-related problems. I'm sure it will be very helpful if it indeed gives people instructive feedback on how to improve their distributions. I look forward to seeing it. When do you suppose it will be up and running?
Not sure I understand how this is different from sussing out any other undeclared prerequisite, though. Is it?
-Ken
