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
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
CPAN Tester Reports (Score:2)
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
Re: (Score:2)
You can't ask the users anything... (Score:1)
> 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
Re: (Score:2)
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
Re: (Score:1)
> 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
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
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
Re: (Score:1)
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.
Re: (Score:1)
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
Nice timing! (Score:1)
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
versioning is broken (Score:1)
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 [blogspot.com] 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
Error in installing DBIx::Class (Score:1)
Re: (Score:2)
PPM is a whole different beastie.
Anybody else notice... (Score:1)
So, ending with the Red Sox reference was a teriffic bit of irony
'Nudder idea... (Score:1)
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
Re: (Score:2)
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
Re: (Score:1)
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
How this (c|sh)ould work... (Score:1)
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 rt.cpan.org? I think so...)
3a) can also