Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

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.