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 going to resemble prove with some added bells and whistles), and if it passes all tests, capture the list of modules loaded during testing and their associated versions (crawling %INC, etc), and put that somewhere as a "test certificate".

    Then, when running your script outside the test suite, it has some pragma like "use only::certified;" that reads the certificate, and loads only the module versions that passed certification testing earlier. Or to put that another way: in order to be used in your script, a particular version of a module must be "certified" for use in your script.

    Later on, newer versions of those modules could be installed, and other scripts on your system could use them, but your script should remain unharmed. If you then decide that you want to try to pick up newer module versions, you run through your certification process again, and only if all the tests pass does a new certificate get generated.

    Obviously, challenges like where do you store the certificates, testing scripts as opposed to modules, and capturing accurate module version info during testing would need considerable thought before something like this could be implemented, but that's the basic outline.

    • 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 (an