Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday January 20, 2006
06:41 AM

"Can't You Just...", CPAN, and Elaine's Law

[ #28412 ]

"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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

"Can't You Just...", CPAN, and Elaine's Law 15 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • One case where, IMO, CPAN seriously goes out the bend, is in the need for external libraries for some XS modules. Take DBD::mysql, XML::Parser, XML::LibXML, Tie::Judy, the various image manipulation modules: all depend on an external library (or more!), of which it's assumed that it's already installed before you even attempt to install the Perl module.

    Very often, the only way to see something is wrong, is because tests are failing in a mysterious way. In other words, the library is not actually treated as
    • 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 a
  • I'm glad someone is coming out and saying it. I still don't [willingly] use M::B to this day because all of the bug/feature/change traffic on it makes me nervous. I know M::B is better than EU::MM. I know I should use it. But everytime I read about issues like this, I always head back to EU::MM because it just works for my needs, and I already have a level of predictibility with it. Add on top of that the fact that Catalyst switched from M::B to Module::Install and all of the app upgrade issues that came
    • 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 i

    • 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 lea

  • Module::Build includes a module for generating Makefile.PL files in various modes. One of them, the "passthrough" mode, creates a Makefile.PL that will attempt to download Module::Build and install it before calling the Build.PL. Obviously, it doesn't expect Module::Build to already be installed for this to happen.

    I don't know how many CPAN authors use this mode, but I always use this or the "parallel Makefile.PL using EU::MM" versions on my cpan uploads, and I've gotten very few bug reports about it.
  • I just want to say, that's an extremely, extremely good idea. And I speak as someone who maintains an installer/dependency solver (urpmi [cpan.org]) for a living.

  • 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?

    • 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.

    • 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.

      • 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 [activestate.com] 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

    --
    /-\

  • 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.