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.

What Modules Does Your Distro *Really* Need? 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If you can use them, I would recommend a virtual server.

    I use Parallels on my mac, but vmware should work the same.

    Create a image with a bare minimal installation of your target OS (I keep 3 or 4 around), and in the final test, boot a pristine copy of it, and try to install your app.

    Not only you'll detect missing CPAN dependencies, but also missing package dependencies that you didn't even know you needed.

    For complex projects, it really tests your deployment documentation :)

    Best regards,
    --
    life is short

    • While that sounds like a fantastic idea (I already have Parallels on my MacBook, along with Vista), I suspect it's a bit more than most developers are looking for, or are able to implement. Ease of use is of paramount importance here. If we can get an 80% solution with 20% of the work, that would be a huge win.

      Of course, if you want to write the code which automates setting all of this up, I'm sure folks would consider it :)

      • qemu debian image with every single Perl pre-installed. :)

        Product of the PITA work, comes in handy from time to time.

        http://pitatesting.net/guests/x86-linux-debian-sarge-perl.tar.gz [pitatesting.net]

        Warning: About 600 meg in size, expands to a 4gig disk image.

        Overkill, ok maybe :)

      • I use Parallels virtual machines for smoke-testing CPAN. I'm normally happy to tell people how to get at a guest account on those VMs if they want to test their modules against minimal installs of various versions of perl.

        So far, I've given access to everyone who's asked. I'd probably only refuse for those very few people who I know abuse community resources. The minimal barrier to entry is that you have to email me to get access.

  • At the end of every test, report %INC and at the end of the test run, report every module in %INC, which version is was released with and if it's not core, check if it's listed as a dependency.

    Perhaps this could be done with a special test target, but I think this is a brillant solution.

    • I was thinking about a test target, though I'm unsure of how to remotely capture %INC. I'm wondering if it's something that would have to be built into each of the tests?

      Now that I stop to think about it, it would be trivial to write a simple Test::More wrapper that Module::Build could load. This would only work with tests which use Test::More, but that would cover the vast majority of them.

    • how could you stop it from reporting the wrong result for

      eval { require Optional::Module; }
      if ($@) {
          # we don't have the module, but we can survive without it..
      }
  • Is there any harm in listing core modules as dependencies?
    • It breaks stuff to list core modules as dependencies. I forget what. Wish I didn't. Sorry.
    • For Debian's dh-make-perl [debian.org], up to the currently-shipping version, we had a manually specified list of core modules. The problem is, this list changes with time. If you take a look at this commit [debian.org], you will agree (I hope!) that automatic querying makes much more sense than hard-coding lists.
  • At the end of every test, report %INC and at the end of the test run, report every module in %INC, which version is was released with and if it's not core, check if it's listed as a dependency.

    Woah there! I agree this would be a nice author test, but it's is much harder than just using %INC.

    1) Testing for core status
    --> For what version of perl? Needs to know what's the minimum version of perl this module runs on. I think since there is no META.yml attribute which is reliable and agreed upon, this needs

    • For what version of perl?

      Module::CoreList [cpan.org]

      I have no idea what compells you to mention PPI in this context.

      I think this sort of module would only do good if it had a robust implementation and that is probably very hard.

      You think a simple implementation that gets us ¾ of the value of a completely airtight implementation is worthless? Why?

      • I have no idea what compells you to mention PPI in this context.

        That's because you misunderstood me. Given a distribution to be tested, you need to know the minimum perl version it's compatible with to be able to USE Module::CoreList at all. To get a list of core modules, you need a perl version, remember? I mention PPI because it's used to implement Perl::MinimumVersion.

        You think a simple implementation that gets us ¾ of the value of a completely airtight implementation is worthless? Why?

        Because suppo

        • Given a distribution to be tested, you need to know the minimum perl version it’s compatible with

          Ah. I can see that in your previous comment now, but you weren’t quite explicit enough about the point, so I didn’t understand you correctly on first read.

          If you implement it as a separate make/Build target

          I thought it was a given that checking the dependency list is done before you upload to PAUSE. This sort of test would be useless if it ran after your distro ship had sailed.

          • I thought it was a given that checking the dependency list is done before you upload to PAUSE. This sort of test would be useless if it ran after your distro ship had sailed.

            How touchingly naive :-) It's amazing how many people don't bother checking. Aside from plain and simple coding errors, undeclared dependencies are one of the most common problems with modules. It's hard to blame the authors though. If you use LWP::UserAgent every day it's hard to remember that it's not core. Even harder to remem

            • No, what I meant is that I thought it was a given that any automatic depency list checker would be for use before, not after, uploading.

              If anyone thought people always checked the list themselves, we wouldn’t even be having this discussion…

  • I used to have this problem quite a bit, but then I wrote Test::Prereq. That module runs all the tests and collects module information along the way. It then removes the core modules, looks in Makefile.PL (or Build.PL) to see what is listed. Everything left over is something you should have listed as a dependency.
  • We in Debian [debian.org] have several tools for building our packages in bare environments - That is, tools that set up an essential system, add the dependencies declared in any given package, and build the package in it. My personal favorite is Cowbuilder [debian.org], heavily based on Pbuilder [debian.org].
    For something closer to The Perl Way, we have good ol' dirty dh-make-perl [debian.org], which takes a CPAN package, extracts -among other things- its dependencies, and builds (or at least, tries to - But if it doesn't, we treat it as a bug) a Debian pac
  • I guess similar packages will exist for other distributions - pbuilder sets up a minimal chrooted system with only the base packages for the OS, and builds Debian packages in them, satisfying the build-dependencies each package declares and thus ensuring that they are _buildable_ with nothing but what is declared (i.e. no dependencies already present in the maintainer's build environment are skipped).
    Now, this approach is good for building packages, not necessarily for testing Perl modules' completeness. Of
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.