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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • A long time ago, after a talk that Ingy gave about only.pm, I mentioned to him an idea I had that would avoid hard coding module versions into scripts, but would address the common issue that makes people want to use only.pm in the first place - that your script used to work, but installation of a later version of a module breaks it. And moreover, it leverages one of our favorite topics - testing!

    The basic idea is that you write a test suite for your script, run the suite (using some tool that's probably

    • Interesting idea, but it's still a "freeze the world" solution and doesn't address the "works on my machine" problem.

      CPAN failures are often caused by cross-platform issues. What if the person who wrote the certificate was using a different version of Perl, operating system, file system, configuration of Perl, etc... than you?

      However, the basic idea is interesting. I've pondered how one could harvest CPAN testers information to produce a map of what versions of what modules on what platforms work with oth
      • I probably should have clarified that the idea I was proposing was for local use on a given box, not a CPAN-wide certification. So, for what I want to use it for, it doesn't necessarily feed any useful info back up the chain to the module developer (but I guess it could be extended to, in a CPAN Testers kind of way). But it does address what I consider to be an all too common situation: my script worked yesterday, it doesn't work today, what happened?

        Basically, the common use case that I'm picturing (and have personally endured pain from before), is at an ISP with a shared server: you get your script working happily with the set of modules that happen to be installed on a given day, then the ISP upgrades some module to satisfy some other user, and suddenly your script quits working - or even worse, it silently starts doing the wrong thing! This is a big reason why many ISPs take a very conservative approach to installing or upgrading CPAN modules. Which has the disadvantage that you end up having to wait months or even years to pick up the bugfixes and new features that might be available in the latest versions (unless you then choose to install into your own dir, but that's a whole different kettle of fish :).

        So, whereas you see this as a "freeze the world" approach, I see it as a trying to stop "spooky action at a distance" approach. There are few things more frustrating than having a script that you didn't change one bit break due to something that someone else did, somewhere else.

        Another way to view it, is that we're following the test driven development model so much when writing modules, that we try to have appropriate tests in place before changing even one line of _our_ code, but after that we're willing to magically snarf in changes from anyone else's code willy-nilly. Sometimes that feels a little penny wise, pound foolish. Or maybe we just trust others more than ourselves ;).