Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Dist-Zilla-Plugin-Test-ReportPrereqs CPAN distribution.

Report information
The Basics
Id: 85806
Status: resolved
Priority: 0/
Queue: Dist-Zilla-Plugin-Test-ReportPrereqs

People
Owner: Nobody in particular
Requestors: BBYRD [...] cpan.org
Cc: ether [...] cpan.org
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Columns: type and requirement level
Since this is the new fangled ReportPrereqs module for DZIL, I figured I'd ask you about something I've wanted in all of them: something to separate out the required modules from the recommended ones. It makes it easier to look at the module list at a glance and show that all of the -required- modules are installed, even if some of the -recommended- ones aren't. As you use a column-based format, just adding a few more columns seems like the logical design choice here. Sorting these by [reqlevel, type, alpha] would be ideal, too.
Subject: Re: [rt.cpan.org #85806] Columns: type and requirement level
Date: Sun, 2 Jun 2013 15:01:57 -0400
To: bug-Dist-Zilla-Plugin-Test-ReportPrereqs [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
It doesn't really work so easily. You could "require foo 1.0" but "recommend foo 1.2". The prerequisite list is a constraint specification. Can you show me the output you want? It might be easier to understand what you're asking for that way. On Sun, Jun 2, 2013 at 2:38 PM, Brendan Byrd via RT <bug-Dist-Zilla-Plugin-Test-ReportPrereqs@rt.cpan.org> wrote: Show quoted text
> Sun Jun 02 14:38:15 2013: Request 85806 was acted upon. > Transaction: Ticket created by BBYRD > Queue: Dist-Zilla-Plugin-Test-ReportPrereqs > Subject: Columns: type and requirement level > Broken in: (no value) > Severity: Wishlist > Owner: Nobody > Requestors: BBYRD@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=85806 > > > > Since this is the new fangled ReportPrereqs module for DZIL, I figured I'd ask you about something I've wanted in all of them: something to separate out the required modules from the recommended ones. It makes it easier to look at the module list at a glance and show that all of the -required- modules are installed, even if some of the -recommended- ones aren't. > > As you use a column-based format, just adding a few more columns seems like the logical design choice here. Sorting these by [reqlevel, type, alpha] would be ideal, too.
-- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
On Sun Jun 02 15:02:41 2013, DAGOLDEN wrote: Show quoted text
> It doesn't really work so easily. You could "require foo 1.0" but > "recommend foo 1.2". The prerequisite list is a constraint > specification.
I would say that in those cases, it should add in duplicate entries. But, that's an edge case. (I mean, you have to manually add in all recommend modules in your dist.ini, anyway.) The most common case would be different modules that may or may not be installed on the user's machine. Show quoted text
> Can you show me the output you want? It might be easier to understand > what you're asking for that way.
It could look something like this: # Phase Relationship Version Module # ------- ------------ ------- ------------------- # Build Requires 6.66 ExtUtils::MakeMaker # # Runtime Requires 1.110 Foo::Bar # Runtime Requires 1.110 Foo::Bar::Coolness # Runtime Requires 1.26 Carp # Runtime Requires 2.0802 Class::MOP # Runtime Requires 3.40 Cwd # Runtime Requires 2.24 Date::Format # Runtime Requires 2.30 Date::Parse # # Runtime Recommends missing YAML::Syck # Runtime Recommends missing Email::Simple # # Test Requires 0.98 Test::More # Test Requires 1.2000 Time::Local # Test Requires 0.12 Try::Tiny Or, if the repetition is too ugly, then something like this: # Version Module # ------- ------------------- # === Build Requires === # 6.66 ExtUtils::MakeMaker # # === Runtime Requires === # 1.110 Foo::Bar # 1.110 Foo::Bar::Coolness # 1.26 Carp # 2.0802 Class::MOP # 3.40 Cwd # 2.24 Date::Format # 2.30 Date::Parse # # === Runtime Recommends === # missing YAML::Syck # missing Email::Simple # # === Test Requires === # 0.98 Test::More # 1.2000 Time::Local # 0.12 Try::Tiny Whatever style works for you. The point is that you don't have a huge list of dependencies, with these two missing ones, and don't freak out that and say "Well, there's your problem... you have these two required dependencies missing here." Only to find out that they aren't actually required in the first place. Sorting would done as: (phase, relationship, alpha), with the first two in the order listed here: https://metacpan.org/module/CPAN::Meta::Spec#PREREQUISITES (And I should probably be using Suggests more often, but I digress...)
The idea here is sane, but it would probably need several iterations to "look right". I'd find it useful seeing runtime+test requirements separated from develop, and requires separated from recommend.... also "want" and "have" in two columns, much like many of the cpantesters reports generate. Sineswiper, are you still keen on this? I'd be happy to collaborate on a wiki page to figure out the layout... once that's solid, actually doing the implementation is pretty trivial --> https://github.com/dagolden/Dist-Zilla-Plugin-Test-ReportPrereqs/wiki
On Tue Oct 15 20:18:59 2013, ETHER wrote: Show quoted text
> Sineswiper, are you still keen on this? I'd be happy to collaborate on > a wiki page to figure out the layout... once that's solid, actually > doing the implementation is pretty trivial --> > https://github.com/dagolden/Dist-Zilla-Plugin-Test-ReportPrereqs/wiki
Yeah, this is still something that I want, if that is what you're asking. Looking back on the examples I provided, the header-based format (2nd example) seems to look nicer.