Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • An interesting idea. It actually crossed my mind that in many cases CPAN Testers spot these sort of incompatibilities, but with the scale of the reports and CPAN it could get tricky and very time consuming to review them all. Or were you only thinking of doing this with major distributions (e.g. Phalanx 100?), or when an actual user hits a problem?

    Once PITA is up and running, this sort of confirmation of fixes could be done fairly quickly, perhaps with an automated test harness that tests notable combinati

    • Just humans. We usually know what's wrong, we just don't have a way of letting the installers know.
  • > What happens is when there's a dependency problem, say a bug fix in
    > Test::More reveals test failures in DBI (which it does), the author of
    > the dependent module (Andreas) can report a CPAN Version Advisory that
    > DBI 1.59 and Test::More >= 0.71 are incompatible. When a user goes to
    > install DBI the CPAN shell queries the service for any advisories. It
    > uses that information to decide what to do. In this case it might say
    > "DBI 1.59 is incompatible with your installed version of Tes
    • It's going to be extremely difficult for users in this situation. If we apply the "7 layers of recursion" principle, how are they going to have any idea what to do in this situation?

      It provides the user with *some* information and a way out, as opposed to nothing. Part of the point is just to make this sort of ad-hoc information that we normally communicate via word-of-mouth available to the world in a human and machine readable format.

      But I see your point. Yes, the downgrading may be problematic, but i

      • > It requires the author's intervention. Often the very problem is that an
        > author is not being responsive. It does not address the bottleneck issue.
        > You could just have the CPAN cabal unilaterally decide to yank a module from
        > the index, but this is not a happy making thing, CPAN has always been very
        > hands off, and it just moves the bottleneck to the CPAN cabal. The advisories
        > allow either end of the relationship to report the problem.

        As I understand it, in your description it's the CP
        • My mistake, that should have said "Tim". Fixed that.

          To clarify, the people issuing the advisories are the authors of the modules effected. The author on either side of the relationship can issue the advisory, so in my Test::More / DBI example it's either me or Tim Bunce.

          It's also possible that a 2nd or 3rd order dependent could issue an advisory. So, say, Matt Trout could issue the Test::More / DBI advisory because DBIx::Class needs DBI and his users are effected by the breakage.

          There would also be trust
    • So they agree to a downgrade (which doesn’t REALLY know how to do properly anyway, except by installing over the top of the newer version) and now they have an older version of a module which breaks a dependency of something ELSE which needed the new version to work.

      Of course, as with most things dependency-related, Debian got that right a long time ago, by tracking “reverse dependencies”, ie. not just what packages a package depends on, but also which packages it is a depeden

      • Debian is an excellent binary repository, but it is most certainly NOT a great model if you have a source repository.

        For example, our dependencies are complete (programatic in nature), vary across platforms and as such it's extremely difficult to know downstream deps.

        That said, for any given host, you can "localize" the dependencies to static form, which could perhaps them be saved somehow...

        The META.yml -> META-LOCAL.yml idea is looking better and better.
        • I don’t know what difference source vs binary would make in this case. The local inventory of installed software almost always differs from the repository, which generally only tracks information about the newest version of every package. So to use reverse dependency checks you always have to record them locally after each successful installation, anyway.

          The CPAN client would have to determine the local final list of dependencies and then figure in the recorded reverse dependencies, and could then t

  • This is well timed. A cpan-testers report [] from David Cantrell today revealed that Perl::Critic 1.072 made an API change that broke Perl::Critic::More. It's been broken for two weeks and 6 minor releases of Perl::Critic, but nobody noticed.

    So, we'll probably push out a Perl::Critic 1.078 soon, but in the meantime, you have to choose between Perl::Critic bug fixes or Perl::Critic::More passing its tests.

    The sad thing is that the failure happened while a test script was trying to decided if it was in "author
  • The basic problem is that putting the burden of "what version can I use?" on the user is broken. By user I mean author of a module which uses another module. The library maintainer knows far more about compatibility than the average user and so the library maintainer should be able to publish that information (out of band).

    This post [] goes quite a bit further (probably too far for Perl). I actually implemented the engine for the abstract stuff in that post but the most important aspect is actually the int

  • When I try to install DBIx::Class on WinXP with PPM, the error ocurs as follows: ERROR: File conflict for 'C:/Perl/html/site/lib/Test/Builder/Tester/Color.html'. The package Test-Simple has already installed a file that package Test-Builder-Tester wants to install. Who could help me? Thanks!!!
    • Contact the person who made those PPMs, probably somebody at ActiveState.

      PPM is a whole different beastie.
  • As I was reading the "Traffic Report" I thought to myself that it sounded just like the helicopter broadcasts on WBZ-1030 (AM Radio) here around Boston...

    So, ending with the Red Sox reference was a teriffic bit of irony :)
  • A long time ago, after a talk that Ingy gave about, 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 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 (an

  • Sorry if this is a little bit terse, I don't have much time...

    1) Module authors list dependencies of their modules in Makefile.PL/Meta.yml (they already do, don't they?)

    2) PAUSE parses this info and puts it into a cross-reference DB.

    3) Authors can enter compatibility info into this DB via web interface, just saying "module M works with version X of module A and version Y of module B" or "module M doesn't work with version Z of module C". (could/should this be part of I think so...)

    3a) can also