Re: cascading used-by metrics on CPANTS?

[David Cantrell]

On Mon, Aug 09, 2010 at 12:50:12PM -0500, David Nicol wrote:
> I was a little surprised that when module A is used by module B and
> module B is used by modules C,D,E,F,G there is no indication of the
> requirement by C,D,E,F,G on http://cpants.perl.org/dist/used_by/A
> I think a "cascading use" list would be useful on the used_by pages on CPANTS.

AFAIK CPANTS is pretty much dead.  Which is why I implemented this as
part of CPANdeps:
  http://deps.cpantesters.org/depended-on-by.pl?dist=Scalar-List-Utils-1.23

of course, it still only goes one level deep, and it's a nasty crude
hack, but patches are welcome!

The password for git is the same as the username, cos I couldn't persuade
Linux and ssh to permit no password at all.

-- 
David Cantrell | top google result for "internet beard fetish club"

The Law of Daves: in any gathering of technical people, the
number of Daves will be greater than the number of women.

cascading used-by metrics on CPANTS?

[David Nicol]

I was a little surprised that when module A is used by module B and
module B is used by modules C,D,E,F,G there is no indication of the
requirement by C,D,E,F,G on http://cpants.perl.org/dist/used_by/A

I think a "cascading use" list would be useful on the used_by pages on CPANTS.

Re: looking for CPANTS (co-) maintainers

[Shlomi Fish]

On Monday 29 June 2009 23:03:00 Thomas Klausner wrote:
> Hi!
>
> See over there: http://use.perl.org/~domm/journal/39189

Hi Thomas!

Is this the reason that CPANTS was out-of-date for a long time? It seemed 
better yesterday, though.

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
"The Human Hacking Field Guide" - http://xrl.us/bjn8q

God gave us two eyes and ten fingers so we will type five times as much as we
read.

looking for CPANTS (co-) maintainers

[Thomas Klausner]

Hi!

See over there: http://use.perl.org/~domm/journal/39189


-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: Getting CPANTS to update?

[Marc Lucksch]

Marc Lucksch schrieb:

I fear I have done something to CPANTS with my Dotiac::DTL module, the version 
counter doesn't increase anymore. It is still set to 0.5 
(http://cpants.perl.org/dist/overview/Dotiac), even though 0.8 is already out.

Is this an error on my part, or do I just have to wait?

Sincerely yours,

Marc "Maluku" Lucksch
Somehow this took almost a day to appear here, I thought it got lost. 
Sorry for that...


Maluku

Re: CPANTS not updating some modules?

[Thomas Klausner]

Hi!

On Tue, Feb 10, 2009 at 10:31:28AM +0100, Marc Lucksch wrote:
> The update for some of my modules seems lost somehow
> Dotiac: Still 0.5, but 0.8_1 is the latest
> Dotiac-addon-html_template is missing completely.
>
> Is this an error on my part, or is there a bug somewhere?

Very likely a bug somewhere, but as I'm _very_ low on tuits atm 
(girlfriend away writing her dissertation so I'm now single parent for 4 
months, just came back from holiday, where I got ill, which I still am, 
and there's this $work deadline next month...) it might take a while 
until I find some time...


-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Getting CPANTS to update?

[Marc Lucksch]

I fear I have done something to CPANTS with my Dotiac::DTL module, the version 
counter doesn't increase anymore. It is still set to 0.5 
(http://cpants.perl.org/dist/overview/Dotiac), even though 0.8 is already out.

Is this an error on my part, or do I just have to wait?

Sincerely yours,

Marc "Maluku" Lucksch

CPANTS not updating some modules?

[Marc Lucksch]

The update for some of my modules seems lost somehow
Dotiac: Still 0.5, but 0.8_1 is the latest
Dotiac-addon-html_template is missing completely.

Is this an error on my part, or is there a bug somewhere?

Marc "Maluku" Lucksch

Module::CPANTS::Analyse has_test_pod fails on my module but it has pod tests

[Martin Evans]

Hi,

I have recently been taking more notice of CPANTS and made some changes 
to DBD::ODBC to get more "kwalitee". I'm basically getting a fail on 
has_test_pod (http://cpants.perl.org/dist/kwalitee/DBD-ODBC) which I've 
duplicated myself with Module::CPANTS::Analyse. However, I have a pod 
test (although it might look a strange one):


use Test::More;
my $has_test_nowarnings = 1;
eval "require Test::NoWarnings";
$has_test_nowarnings = undef if $@;

END {
Test::NoWarnings::had_no_warnings()
  if ($has_test_nowarnings);
}

# I need to include Test::NoWarnings to pass cpants but that adds a test
# so that prevents you using all_pod_files_ok as that sets the
# Test::More plan.

my $tests = 3;
$tests += 1 if $has_test_nowarnings;
eval "use Test::Pod 1.00 tests => $tests";
plan skip_all => "Test::Pod 1.00 required for testing POD" if $@;
my @pods = all_pod_files();
foreach my $pod (@pods) {
next if $pod !~ /(ODBC.pm)|(FAQ.pm)|(Changes.pm)/;
pod_file_ok($pod);
}

I did not want to insist on anyone having Test::Pod.

I was previously not using Test::NoWarnings (also changed for kwalitee) 
but I did not like to insist on anyone having Test::NoWarnings because 
it is not a core module and is only required for the test. However, 
all_pod_files_ok sets the number of tests itself so I had to split the 
tests up as above in case someone did not have Test::NoWarnings. 
Analyse.pm does not seem to spot my use of Test::Pod.


Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: CPANTS "has_example" metric confusion

[Paul Fenwick]

David Golden wrote:

I believe you actually need to put a file into it and include it in
the MANIFEST, otherwise, an empty directory doesn't get included in
the distribution.


Sorry, I should have mentioned that it:

1) Is in the MANIFEST
2) Is in the distribution
3) Contains a real example of working code

Cheerio,

Paul

--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training   | Ph:  +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681

Re: CPANTS "has_example" metric confusion

[David Golden]

I believe you actually need to put a file into it and include it in
the MANIFEST, otherwise, an empty directory doesn't get included in
the distribution.

David

On Fri, Jul 18, 2008 at 9:57 AM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> G'day Perl-QA,
>
> I'm afraid I'm rather confused about the CPANTS "has_example" metric.  The
> remedy is listed as:
>
>Add a directory matching the regex (bin|scripts?|ex|eg|examples?|
>samples?|demos?) ... to your distribution that includes some
>scripts showing one or more use-cases of the distribution.
>
> At least one of my modules has an examples directory, and yet is still
> failing the test:
>
>http://cpants.perl.org/dist/kwalitee/IPC-System-Simple
>
>http://search.cpan.org/src/PJF/IPC-System-Simple-0.13/examples/
>
> Is CPANTS looking for something besides the directory, or have I hit
> something particularly odd here?
>
> Many thanks,
>
>Paul
>
> P.S. IPC::System::Simple 0.14 is going to CPAN in the next hour, but I'm not
> changing its examples directory, so I expect the problem to continue to
> persist.
>
> --
> Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
> Director of Training   | Ph:  +61 3 9354 6001
> Perl Training Australia| Fax: +61 3 9354 2681
>

CPANTS "has_example" metric confusion

[Paul Fenwick]

G'day Perl-QA,

I'm afraid I'm rather confused about the CPANTS "has_example" metric.  The 
remedy is listed as:


Add a directory matching the regex (bin|scripts?|ex|eg|examples?|
samples?|demos?) ... to your distribution that includes some
scripts showing one or more use-cases of the distribution.

At least one of my modules has an examples directory, and yet is still 
failing the test:


http://cpants.perl.org/dist/kwalitee/IPC-System-Simple

http://search.cpan.org/src/PJF/IPC-System-Simple-0.13/examples/

Is CPANTS looking for something besides the directory, or have I hit 
something particularly odd here?


Many thanks,

Paul

P.S. IPC::System::Simple 0.14 is going to CPAN in the next hour, but I'm not 
changing its examples directory, so I expect the problem to continue to persist.


--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training   | Ph:  +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681

Re: The Definitive CPANTs Summary

[Andy Lester]

On Jul 1, 2008, at 3:29 AM, Ovid wrote:


1.  CPANTs was not only fun, but it was (and is) helpful.
2.  "Non-kwalitee" metrics crept in.
3.  Some people are upset about gaming.
4.  Some people love gaming.
5.  Many people can reasonably disagree on what "value" means.



Note that nowhere in here does the word "user" appear.

xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

The Definitive CPANTs Summary

[Ovid]

He's what I saw in the thread.

1.  CPANTs was not only fun, but it was (and is) helpful.
2.  "Non-kwalitee" metrics crept in.
3.  Some people are upset about gaming.
4.  Some people love gaming.
5.  Many people can reasonably disagree on what "value" means.

Too many people (including me!) forget to guard their tone (it's a nasty habit 
I have).  That's why I stopped reading this thread.  I don't want to see that.

To Thomas and everyone else (I don't know the definitive list) who've worked on 
CPANts, thank you!  You've not only done a great job, but you've improved both 
Kwalitee and Quality on the CPAN.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter  - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6

Re: New CPANTS metrics

[Gabor Szabo]

On Wed, Jun 11, 2008 at 5:26 AM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> I think a good solution is to add a new category called "honours".  It is an
> honour to have your module packaged by Debian, included in the ActiveState
> distro, or to be used by another CPAN module.  For honours, we only mention
> what honours a module has received, not what it hasn't.  For example, an
> honours list may read:
>
>* Packaged by Debian.
>* Included with ActiveState Perl 5.8.8
>* Given a 5 star review on cpanratings
>
> The important thing is that the list doesn't mention all the honours that
> haven't been received (packaged by RedHat, sent to the moon, included as a
> dual-life core module etc).  Honours don't contribute to the kwalitee score.
>
> The end result is authors feel good about their honours page (it doesn't
> show at all if there are no honours), the kwalitee metrics continue to
> measure things an author can reasonably fix, and end-developers using CPANTS
> for research won't be turned off by a large number of red 'optional metrics'
> from an otherwise excellent module.

Sounds like a good idea!

We were also thinking with Thomas on how to mark the other 3 debian
related metrics to be dependent on the "packaged_by_debian" metric.
After all if the module is not packaged by debian then the other 3
have no meaning.

So if a module is packaged by debian it will get it
"packaged_by_debian" "honour"
metric turned on. Then she will also see 3 new metrics where she has
partial control.
e.g. she can fetch the patch include it in the official distribution
on CPAN and notify the
Debian maintainers to upgrade.

Gabor

-- 
Gabor Szabo http://szabgab.com/blog.html
Test Automation Tips http://szabgab.com/test_automation_tips.html

Re: New CPANTS metrics

[Paul Fenwick]

G'day Everyone,

brian d foy wrote:


I'd like to see the metircs that only talk about the quality of the
distribution, and leave everything else alone. If it's something I can
fix by doing something to the distribution itself, measure it. If it's
anything else, leave it out.


Gabor Szabo wrote:


I wanted the Debian specific metrics there in order to give feedback to
the authors so they know what's the status of their module in Debian.


I think that telling people that they've been packaged in Debian or 
elsewhere is great.  It's certainly feedback I'd like to see.  It's 
certainly an indication that someone things the module is worthwhile.


However I'm with brian here that having metrics that can't be improved just 
by doing something to the distribution itself makes for a sticky situation. 
I want to score points on all the optional metrics I can, but some of my 
modules (like App::SweeperBot) will never be packaged on Debian, because 
they just don't run there.


I think a good solution is to add a new category called "honours".  It is an 
honour to have your module packaged by Debian, included in the ActiveState 
distro, or to be used by another CPAN module.  For honours, we only mention 
what honours a module has received, not what it hasn't.  For example, an 
honours list may read:


* Packaged by Debian.
* Included with ActiveState Perl 5.8.8
* Given a 5 star review on cpanratings

The important thing is that the list doesn't mention all the honours that 
haven't been received (packaged by RedHat, sent to the moon, included as a 
dual-life core module etc).  Honours don't contribute to the kwalitee score.


The end result is authors feel good about their honours page (it doesn't 
show at all if there are no honours), the kwalitee metrics continue to 
measure things an author can reasonably fix, and end-developers using CPANTS 
for research won't be turned off by a large number of red 'optional metrics' 
from an otherwise excellent module.


Cheerio,

Paul

--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training   | Ph:  +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681

Re: New CPANTS metrics

[Gabor Szabo]

On Tue, Jun 10, 2008 at 10:37 PM, Ricardo SIGNES
<[EMAIL PROTECTED]> wrote:
> * brian d foy <[EMAIL PROTECTED]> [2008-06-10T12:27:29]
>> I'd like to see the metircs that only talk about the quality of the
>> distribution, and leave everything else alone. If it's something I can
>> fix by doing something to the distribution itself, measure it. If it's
>> anything else, leave it out. :)
>
> Given that CPANTS has been discussed as a tool to help authors write better
> dists, I think this is a very, very good suggestion.
>
> Gathering other information is great.  I'd like to know if there Debian is
> packaging my code.  It just isn't as much about "your code seems to be
> well-produced."

At one point I'd like to add a tool to CPANTS so people can give
weights to each one
of the metrics and see their 'kwalitee' through that magic weight system.

So you could say

10 for has_test and
1 use_warnings
0 for debian_redistributes
etc.

Once this is implemented it will be interesting to see what weights people
use for each metric.

I wanted the Debian specific metrics there in order to give feedback
to the authors so
they know what's the status of their module in Debian. (and I hope I
can add more distros)
It could be gathered in yet another site but I thought it might have a
better place in CPANTS.
I also think it has high added value to the kwalitee metrics but let's
not discuss that again.

Gabor

Re: New CPANTS metrics

[Ricardo SIGNES]

* brian d foy <[EMAIL PROTECTED]> [2008-06-10T12:27:29]
> I'd like to see the metircs that only talk about the quality of the
> distribution, and leave everything else alone. If it's something I can
> fix by doing something to the distribution itself, measure it. If it's
> anything else, leave it out. :)

Given that CPANTS has been discussed as a tool to help authors write better
dists, I think this is a very, very good suggestion.

Gathering other information is great.  I'd like to know if there Debian is
packaging my code.  It just isn't as much about "your code seems to be
well-produced."

-- 
rjbs

Re: New CPANTS metrics

[David Golden]

On Tue, Jun 10, 2008 at 12:27 PM, brian d foy <[EMAIL PROTECTED]> wrote:
> I'd like to see the metircs that only talk about the quality of the
> distribution, and leave everything else alone. If it's something I can
> fix by doing something to the distribution itself, measure it. If it's
> anything else, leave it out. :)

+1

-- David

Re: New CPANTS metrics

[brian d foy]

In article <[EMAIL PROTECTED]>,
David Golden <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 9, 2008 at 4:32 PM, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > I am sending this to both the module-authors list so you can be
> > aware of the new metrics and the perl-qa list as they might
> > have a few words as well regarding kwalitee.
> 
> First, I have to say that I applaud and appreciate the effort that
> goes into developing new Kwalitee metrics -- however, I think that
> many ideas wind up less interesting or relevant than initially
> thought.

I'd like to see the metircs that only talk about the quality of the
distribution, and leave everything else alone. If it's something I can
fix by doing something to the distribution itself, measure it. If it's
anything else, leave it out. :)

Re: New CPANTS metrics

[David Golden]

On Mon, Jun 9, 2008 at 4:32 PM, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> I am sending this to both the module-authors list so you can be
> aware of the new metrics and the perl-qa list as they might
> have a few words as well regarding kwalitee.

First, I have to say that I applaud and appreciate the effort that
goes into developing new Kwalitee metrics -- however, I think that
many ideas wind up less interesting or relevant than initially
thought.  I think that too many measures of little interest will lead
authors to ignore CPANTS rather than optimize against it.  That may be
a feature or a deficiency, depending on one's perspective.

Personally, I find that metrics of "inclusion" -- eg. in Debian -- are
somewhat interesting, not unlike being a prerequisite for other
modules.  However, beyond that initial fact, fine distinctions around
bugs/patches/etc. seem a bit too idiosyncratic.  And as someone
invested in development on Win32, I also see chromatic's point that
isn't a very portable metric, which would be a shame to see for Perl
'Kwalitee".  More useful might be a "redistributed" Kwalitee score,
that looks to see whether something is distributed as part of a
standard perl installation.  E.g. XML::Parser is now bundled with
Strawberry Perl and I think by ActiveState as well.

A challenge to such metrics is what "distributed by" means.  I recall
at Oslo someone was trying to get thousands of CPAN modules to build
as packages for FreeBSD so that CPAN modules all get managed through
the same package management system, not a parallel one via CPAN.pm.
Does that count as "distributed"?

I think the Test::NoWarnings measure is fundamentally misguided.  I
generally think any Kwalitee metric that mandates the use of
particular modules is misguided, so some criticisms I have relate to
that. For instance, if I decide to write and use
"Test::NoWarnings::Plus", that has all the features of
Test::NoWarnings, should my Kwalitee go down?  If I write my own
testing framework that doesn't use Test::More, what then?

And encouraging widespread use of a module may not be a good idea if
it problems in that module would cause many CPAN distributions to fail
tests.   That already happens with Test::More.  I don't want to add
more distributions to a critical toolchain.

Moreover, Test::NoWarnings doesn't actually check that code doesn't
issue warnings.  It just checks that code doesn't call 'warn' against
the default warnings handler.  E.g.

use Test::More tests => 1;
use Test::NoWarnings;
print STDERR "This warning isn't caught by Test::NoWarnings\n";
sub log_error {} # would normally do something interesting
local $SIG{__WARN__} = sub { log_error(@_); print STDERR @_, "\n" };
warn "This warning isn't caught either";

[As an aside, the Test::NoWarnings docs imply I shouldn't need a
Test::More plan, but apparently I do.]

So even if one thinks that Kwalitee implies not issuing warnings,
Test::NoWarnings isn't the right way to test for that.  I'm not sure
there is a good way.  Check for stuff on STDERR?  That too probably
has issues.

> There are two issues regarding the criticism:
> 1) I did not find any mention of any new metric that would be good.

When you propose new metrics and ask for comments, I don't think
you're likely to get new metrics proposed.  You probably should ask
for those in a separate thread.

> 2) True, it would be great if more of the module authors knew about
> CPANTS and cared. I agree so how could we let them know about
> it besides posting on use.perl.org and on this mailing list?
> Maybe http://perlbuzz.com/ ? Any other ideas?

Have links to the relevant CPANTS pages added to the search.cpan.org
author and distribution pages.

Regards,
David

New CPANTS metrics

[Gabor Szabo]

Two days ago or so I posted a blog entry about the new CPANTS metrics.
http://szabgab.com/blog/2008/06/1212827982.html

I am glad that already there are some comments about them
even if both chromatic and Andy Lester are well, slightly against them
and even Ovid did not like the Test::NoWarnings metric.
http://use.perl.org/~chromatic/journal/36627

I know they all are authorities in matters of quality but I hope at some
point I might be able to either convince them or learn from them how
to improve these metrics.

Anyway, shall we leave all the fun to the use.perl.org readers only?

I am sending this to both the module-authors list so you can be
aware of the new metrics and the perl-qa list as they might
have a few words as well regarding kwalitee.

BTW if you go to CPANTS http://cpants.perl.org/
you will see that all the new metrics are marked as experimental
and as such by default they are not supposed to be displayed.

Also if you as a module author are interested in what's the status of
your module in downstream distros (well, currently only debian)
then you can go to CPANTS and check it out.

There are two issues regarding the criticism:
1) I did not find any mention of any new metric that would be good.
I'd be really glad to hear ideas of what could be a good metric?

2) True, it would be great if more of the module authors knew about
 CPANTS and cared. I agree so how could we let them know about
 it besides posting on use.perl.org and on this mailing list?
 Maybe http://perlbuzz.com/ ? Any other ideas?


regards
   Gabor

-- 
Gabor Szabo http://szabgab.com/blog.html
Test Automation Tips http://szabgab.com/test_automation_tips.html

Re: CPANTS has_separate_license_file test

[Thomas Klausner]

Hi!

On Tue, Jun 03, 2008 at 03:55:38PM +0300, Gabor Szabo wrote:

> > Is CPANTS looking for something special inside the LICENSE file?
> 
> The currently running version of CPANTS has that bug.
> I think I have fixed that already in the SVN we just have to wait till Thomas
> has some time to upgrade the version on the server.

Which will happen tonight. Finally...

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: CPANTS has_separate_license_file test

[Jerome Quelin]

On 08/06/03 15:55 +0300, Gabor Szabo wrote:
> On Tue, Jun 3, 2008 at 3:24 PM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> > The 'has_separate_license_file' test returns 'not ok' on:
> >
> >http://cpants.perl.org/dist/kwalitee/IPC-System-Simple
[...]
> >
> > Is CPANTS looking for something special inside the LICENSE file?
> 
> The currently running version of CPANTS has that bug.
> I think I have fixed that already in the SVN we just have to wait till Thomas
> has some time to upgrade the version on the server.

i reported this some time ago as rt bug 35374
https://rt.cpan.org/Ticket/Display.html?id=35374

no news since then...

jérôme 
-- 
[EMAIL PROTECTED]

Re: CPANTS has_separate_license_file test

[Gabor Szabo]

On Tue, Jun 3, 2008 at 3:24 PM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> G'day QA folks,
>
> I'm gaming my CPANTS quality scores a little, and I've found one of the
> optional metrics has given me an odd result.
>
> The 'has_separate_license_file' test returns 'not ok' on:
>
>http://cpants.perl.org/dist/kwalitee/IPC-System-Simple
>
> However, IPC-System-Simple *does* have a LICENSE file:
>
>http://search.cpan.org/dist/IPC-System-Simple/LICENSE
>
> Is CPANTS looking for something special inside the LICENSE file?

The currently running version of CPANTS has that bug.
I think I have fixed that already in the SVN we just have to wait till Thomas
has some time to upgrade the version on the server.

Gabor

-- 
Gabor Szabo http://szabgab.com/blog.html
Perl Training in Israel http://www.pti.co.il/
Test Automation Tips http://szabgab.com/test_automation_tips.html

CPANTS has_separate_license_file test

[Paul Fenwick]

G'day QA folks,

I'm gaming my CPANTS quality scores a little, and I've found one of the 
optional metrics has given me an odd result.


The 'has_separate_license_file' test returns 'not ok' on:

http://cpants.perl.org/dist/kwalitee/IPC-System-Simple

However, IPC-System-Simple *does* have a LICENSE file:

http://search.cpan.org/dist/IPC-System-Simple/LICENSE

Is CPANTS looking for something special inside the LICENSE file?

Many thanks,

Paul

--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training   | Ph:  +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681

Re: CPANTS Site Seems... Confused

[James E Keenan]

Thomas Klausner wrote:
which wasn't
proof-read by any english speaking person yet, so if @you want to: 
patches welcome ;-)





s/not longer dreadlocked/no longer dreadlocked/

Re: CPANTS Site Seems... Confused

[Thomas Klausner]

Hi!

On Wed, Feb 20, 2008 at 11:52:09AM +0100, Aristotle Pagaltzis wrote:
> * Thomas Klausner <[EMAIL PROTECTED]> [2008-02-19 09:25]:
> > While I was away last week (snowboarding..)
> 
> Do you ever do any actual work, Thomas? :-P

Yes, I do! 

Here's proof: http://revdev.at (the very fresh (we finally put 
something together today) mini-site of our new company which wasn't 
proof-read by any english speaking person yet, so if @you want to: 
patches welcome ;-)

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: CPANTS Site Seems... Confused

[Aristotle Pagaltzis]

* Thomas Klausner <[EMAIL PROTECTED]> [2008-02-19 09:25]:
> While I was away last week (snowboarding..)

Do you ever do any actual work, Thomas? :-P

Regards,
-- 
Aristotle | “If you can’t laugh at yourself,
you don’t take life seriously enough.”

Re: CPANTS Site Seems... Confused

[Randy J. Ray]

>
> While I was away last week (snowboarding..) CPANTS seems to have acquired
> yet another bug. As soon as I have some free time (maybe tomorrow, but
> at the latest this weekend during FOSDEM) I'll take a look.
>
> In the meantime: patches welcome :-) (and comit bits are easily
> obtainable too..)
>

I'll keep that latter part in mind for the future :-), but I suspect that
this current problem may be system-level... I don't think anything has
changed recently in Archive::Tar, so my first impulse is to suspect that the
/tmp partition is full and/or faulty on the hosting machine...

(Ooops, as I was writing this I saw your follow-up that this is indeed the
case! Still, being an ardent fan of the CPANTS game I will consider
contributing when/if I have a few spare tuits :-)

Randy
-- 
Randy J. Ray / [EMAIL PROTECTED]
Silicon Valley Scale Modelers: http://www.svsm.org
Sunnyvale, CA

Re: CPANTS Site Seems... Confused

[Thomas Klausner]

Hi!

On Tue, Feb 19, 2008 at 09:23:38AM +0100, Thomas Klausner wrote:
 
> While I was away last week (snowboarding..) CPANTS seems to have acquired 
> yet another bug. As soon as I have some free time (maybe tomorrow, but 
> at the latest this weekend during FOSDEM) I'll take a look.

It seems that the problem was caused by a full disk (or rather only 16MB 
available on /tmp) on the new machine CPANTS is running on.

I fixed this, and started a new run over all of CPAN, which will take a 
few hours...

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: CPANTS Site Seems... Confused

[Thomas Klausner]

Hi!

On Mon, Feb 18, 2008 at 02:34:15PM -0800, Randy J. Ray wrote:

> information. Just a little while ago, I checked the CPANTS site and noticed
> I had a crapload of red marks, almost all of which are wrong (one of the two
> dists doesn't have LICENSE sections in pod, or a "LICENSE" file). But I'm
> flagged for executable build files (they aren't), no test_pod or
> test_pod_coverage (they are there), Changelog, MANIFEST, README, even tests
> in general!

While I was away last week (snowboarding..) CPANTS seems to have acquired 
yet another bug. As soon as I have some free time (maybe tomorrow, but 
at the latest this weekend during FOSDEM) I'll take a look.

In the meantime: patches welcome :-) (and comit bits are easily 
obtainable too..)

Re: CPANTS Site Seems... Confused

[Randy J. Ray]

>
> If you have already installed Module::CPANTS::Analyse, then you can
> use the cpants_lint script to locally check the CPANTS metrics of
> your distribution before uploading. This makes the game *much*
> easier ;-)
>

Handy to know :-). In this case, however, I had just browsed the source code
on CPAN looking for possible causes.

(I don't remember exactly when they added the "browse source" functionality
to search.cpan.org, but it still gets my vote for "Best Added Feature
EVER"...)

Randy
-- 
Randy J. Ray / [EMAIL PROTECTED]
Silicon Valley Scale Modelers: http://www.svsm.org
Sunnyvale, CA

Re: CPANTS Site Seems... Confused

[Sébastien Aperghis-Tramoni]

Randy J. Ray a écrit :


I've only taken a cursory look at the internals of the
Module::CPANTS::Analyze code, but I noticed that if there is neither
Build.PL or Makefile.PL, you can still trigger an "executable build  
file"
flag-- line 101 of Module::CPANTS::Kwalitee::Files.pm uses the same  
internal
field to indicate this lack as is used to indicate that they're  
executable.
This, combined with the fact that most or all of the other red  
flags seem to
be centered around file issues, leads me to suspect that maybe  
whatever area

the distros are being un-tarred into is having disk issues?


If you have already installed Module::CPANTS::Analyse, then you can  
use the cpants_lint script to locally check the CPANTS metrics of  
your distribution before uploading. This makes the game *much*  
easier ;-)


For example:

 $ cpants_lint ../releases/Win32-Mock-0.04.tar.gz
Checked distWin32-Mock-0.04.tar.gz
Kwalitee rating 112.50% (27/24)

Failed optional Kwalitee tests and
what you can do to solve them:

* prereq_matches_use
List all used modules in META.yml requires

* build_prereq_matches_use
List all modules used in the test suite in META.yml build_requires


--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: CPANTS Site Seems... Confused

[David Golden]

On Feb 18, 2008 5:34 PM, Randy J. Ray <[EMAIL PROTECTED]> wrote:
> This, combined with the fact that most or all of the other red flags seem to
> be centered around file issues, leads me to suspect that maybe whatever area
> the distros are being un-tarred into is having disk issues?

If you look at the error messages, you can see that it does appears to
be some sort of tar issue.  I emailed domm sometime last week, but
haven't heard back.

E.g. http://cpants.perl.org/dist/errors/File-chdir

David

CPANTS Site Seems... Confused

[Randy J. Ray]

I recently (as in, last night) released very minor revs of two of my CPAN
modules. The releases were mostly just correcting/clarifying licensing
information. Just a little while ago, I checked the CPANTS site and noticed
I had a crapload of red marks, almost all of which are wrong (one of the two
dists doesn't have LICENSE sections in pod, or a "LICENSE" file). But I'm
flagged for executable build files (they aren't), no test_pod or
test_pod_coverage (they are there), Changelog, MANIFEST, README, even tests
in general!

I've only taken a cursory look at the internals of the
Module::CPANTS::Analyze code, but I noticed that if there is neither
Build.PL or Makefile.PL, you can still trigger an "executable build file"
flag-- line 101 of Module::CPANTS::Kwalitee::Files.pm uses the same internal
field to indicate this lack as is used to indicate that they're executable.
This, combined with the fact that most or all of the other red flags seem to
be centered around file issues, leads me to suspect that maybe whatever area
the distros are being un-tarred into is having disk issues?

Randy
-- 
Randy J. Ray / [EMAIL PROTECTED]
Silicon Valley Scale Modelers: http://www.svsm.org
Sunnyvale, CA

Re: New proposed CPANTS metric: prereq_matches_use

[Ask Solem Hoel]

On Nov 22, 2007, at 3:47 PM, David Cantrell wrote:


Does the metric include modules used in the test suite? I write my  
test

suites to deal gracefully with missing Test modules.


Most people don't, unfortunately.



Then CPAN testers will catch it.

I don't see how adding author test modules, like Perl::Critic etc, to  
build_requires

will help anything.

And what about Linux::Smaps and other OS specific modules? I imagine a  
lot of things would break

if we are not "allowed" to require modules based on context.


--
Ask Solem
[EMAIL PROTECTED] . +47 41545862]

Re: New proposed CPANTS metric: prereq_matches_use

[Matisse Enzer]

Is the code for implementing this metric available now? I'm interested  
in using it to create a utility that generates the appropriate entries  
in a form suitable for use in Build.PL and Makefile.PL format.


---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: New proposed CPANTS metric: prereq_matches_use

[Thomas Klausner]

Hi!

On Thu, Nov 22, 2007 at 12:25:49PM +0100, David Landgren wrote:

> I have just looked at the latest CPANTS results. I see that all my modules 
> fail this metric... but I am unsure as to why. Consider:
>
>   http://cpants.perl.org/dist/prereq/Integer-Partition
>
> I agree, it's probably best to list Carp, but do I really declare pragmas 
> like 'strict' and 'vars'? How many ISPs remove *them*?

You don't need to. In fact, you don't need to list Core modules (where 
Core is the Perl Version I'm running CPANTS with, which is currently 
5.8.8)

But: Something seems to be broken. And it's quite hellish to debug, 
because all of the prereq stuff needs a DB with all modules, and the 
dists they are in... So if there is an error in the DB, I have to re-run 
everything, which takes hours.

In general, you should find some explanations on the 'Errors' tab:
http://cpants.perl.org/dist/errors/Integer-Partition

Which lists nothing, which is also broken, because you're using some 
non-core Modules in tests, which you do not build_require. (As Barbie 
suggested in private mail, I should also include 'recommends' to the 
list of predeclared test modules, because it is unclear if something 
like Test::Pod is a Build dependency or an optional (test) feature - 
especially if it's used in the proper way (i.e. eval'ed require & SKIP)

> Does the metric include modules used in the test suite? I write my test 
> suites to deal gracefully with missing Test modules.

That's what build_prereq_matches_use is for. Unfortunantly, I cannot see 
an easy way to figure out if a modules is used conditionally (and with 
the neccesary saftey nets)... So maybe this metric is complete crap 
after all...

Anyway, I'll probably remove both prereq_matches_use and 
build_prereq_matches_use in the next days, and try to enhance them so 
that they actually work...

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: New proposed CPANTS metric: prereq_matches_use

[Smylers]

David Cantrell writes:

> On Thu, Nov 22, 2007 at 12:25:49PM +0100, David Landgren wrote:
> 
> > do I really declare pragmas like 'strict' and 'vars'? How many ISPs
> > remove *them*?
> 
> Excluding pragmata that have been in core since at least 5.6 would be
> a good idea, I think.

Really?  Personall I think it would be a _terrible_ idea for ISPs to
exclude such modules from their installations ...

(Oh, I see what you mean.  Sorry!)

Smylers

Re: New proposed CPANTS metric: prereq_matches_use

[David Cantrell]

On Thu, Nov 22, 2007 at 12:25:49PM +0100, David Landgren wrote:
> Thomas Klausner wrote:
> >The metric will be called prereq_matches_use and shall check if all the
> >modules used in a dist are also listed as a prereq.
> 
>   http://cpants.perl.org/dist/prereq/Integer-Partition
> 
> I agree, it's probably best to list Carp, but do I really declare 
> pragmas like 'strict' and 'vars'? How many ISPs remove *them*?

Excluding pragmata that have been in core since at least 5.6 would be a
good idea, I think.

That's attributes, autouse, base, blib, bytes, charnames, constant,
diagnostics, fields, filetest, integer, less, lib, locale, open, ops,
overload, re, sigtrap, strict, subs, utf8, vars, vmsish, warnings, and
warnings::register.

> Does the metric include modules used in the test suite? I write my test 
> suites to deal gracefully with missing Test modules.

Most people don't, unfortunately.

-- 
David Cantrell | top google result for "topless karaoke murders"

  engineer: n. one who, regardless of how much effort he puts in
to a job, will never satisfy either the suits or the scientists

Re: New proposed CPANTS metric: prereq_matches_use

[David Landgren]

Thomas Klausner wrote:

The metric will be called prereq_matches_use and shall check if all the 
modules used in a dist are also listed as a prereq. (prereq is either 
gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or 
Makefile.PL)


As you might know this is quite tricky, because some modules live in 
strange dists (e.g. HTTP::Request -> libwww-perl) and some modules are in 
Core (I'll check this with Module::CoreList).


The first implementation 'simply' selects all distinct dists from all 
modules (of which CPANTS know which dist they are in..) used in a dist, 
and compares this with the distinct dists from all listed prereqs.


I have just looked at the latest CPANTS results. I see that all my 
modules fail this metric... but I am unsure as to why. Consider:


  http://cpants.perl.org/dist/prereq/Integer-Partition

I agree, it's probably best to list Carp, but do I really declare 
pragmas like 'strict' and 'vars'? How many ISPs remove *them*?


Does the metric include modules used in the test suite? I write my test 
suites to deal gracefully with missing Test modules.


David

Re: New proposed CPANTS metric: prereq_matches_use

[David Cantrell]

On Mon, Nov 19, 2007 at 04:30:51PM -0600, Jonathan Rockway wrote:

> I've been yelled at in bug reports and on IRC for adding core modules as
> prereqs

So close the bugs with "no bug found" and /ignore the twits on irc.

-- 
David Cantrell | Godless Liberal Elitist

The Law of Daves: in any gathering of technical people, the
number of Daves will be greater than the number of women.

Re: New proposed CPANTS metric: prereq_matches_use

[Nicholas Clark]

On Mon, Nov 19, 2007 at 03:03:51PM -0800, chromatic wrote:
> On Monday 19 November 2007 14:30:51 Jonathan Rockway wrote:
> 
> > I think the real solution, though, is to agree that the perl interpreter
> > without all of the core modules installed isn't Perl.  (I'm not a big
> > fan of core modules, but the concept is especially worthless if you
> > can't depend on their existence.)

To your own modules?
If so, why on earth is anyone upset about this?

> Any chance you could convince a few thousand ISPs of that?  I'm game.

And this is why.

Nicholas Clark

Re: New proposed CPANTS metric: prereq_matches_use

[David Cantrell]

On Sat, Nov 17, 2007 at 09:47:57PM -0800, Matisse Enzer wrote:
> On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:
> >So in order to make everything work robustly, distros should
> >explicitly list every single module they explicitly use ? no
> >shortcuts, no implications.
> basically, I agree completely, with the possible exception of modules  
> that are in the Perl core

Which version of the perl core?

Taking a fairly common dependency as an example, Storable was introduced
in 5.8.0, so people using 5.6 won't have it unless you declare it as a
pre-requisite.

You need to list anything that isn't core in the minimum version of
perl that you support.  And ideally  say what that minimum version is.

-- 
David Cantrell | top google result for "internet beard fetish club"

Today's previously unreported paraphilia is tomorrow's Internet sensation

Re: New proposed CPANTS metric: prereq_matches_use

[chromatic]

On Monday 19 November 2007 14:30:51 Jonathan Rockway wrote:

> I think the real solution, though, is to agree that the perl interpreter
> without all of the core modules installed isn't Perl.  (I'm not a big
> fan of core modules, but the concept is especially worthless if you
> can't depend on their existence.)

Any chance you could convince a few thousand ISPs of that?  I'm game.

-- c

Re: New proposed CPANTS metric: prereq_matches_use

[Jonathan Rockway]

On Sun, 2007-11-18 at 18:51 -0800, Matisse Enzer wrote:
> On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote:
> >>
> > Even if it's in the perl core, the developer may have compiled with
> >
> >-Dnoextensions=Encode
> >
> > In such a case Encode is not present. I have skipped Encode many times
> > because it takes up so much time, others may do likewise.
> 
> 
> So, I think the bottom line here is: List them ALL in Makefile.PL/ 
> Build.PL

I've been yelled at in bug reports and on IRC for adding core modules as
prereqs  (think upgrading dual-life core modules on older Perl versions;
I guess that's not always desirable.)

I think the best solution would be something like:

 # Makefile.PL
 use 5.8.8;
 requires 'Encode'; # note that I'm not specifying a version; use 5.8.8
does that for me

I think the real solution, though, is to agree that the perl interpreter
without all of the core modules installed isn't Perl.  (I'm not a big
fan of core modules, but the concept is especially worthless if you
can't depend on their existence.)

Regards,
Jonathan Rockway

Re: New proposed CPANTS metric: prereq_matches_use

[Matisse Enzer]

On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote:



Even if it's in the perl core, the developer may have compiled with

   -Dnoextensions=Encode

In such a case Encode is not present. I have skipped Encode many times
because it takes up so much time, others may do likewise.



So, I think the bottom line here is: List them ALL in Makefile.PL/ 
Build.PL


Hmm, sounds like I should create a PPI-based utility that walks a code  
tree and finds all 'use' and 'require' statements and makes a list for  
potential use in Makefile.PL / Build.PL


---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: New proposed CPANTS metric: prereq_matches_use

[Andreas J. Koenig]

> On Sat, 17 Nov 2007 21:47:57 -0800, Matisse Enzer <[EMAIL PROTECTED]> 
> said:

  > On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:

 >> So in order to make everything work robustly, distros should
 >> explicitly list every single module they explicitly use – no
 >> shortcuts, no implications.


  > basically, I agree completely, with the possible exception of modules
  > that are in the Perl core - the standard libraries. On the otehr
  > hand, if a specific version of a standard library is required then it
  > most certainly should be listed, for example:

  >   # In Something.pm
  >   use File::HomeDir 0.66;

  > and

  >  # In Makefile.PL
  >  PREREQ_PM=> { 'File::HomeDir' => '0.66' },

Even if it's in the perl core, the developer may have compiled with 

-Dnoextensions=Encode

In such a case Encode is not present. I have skipped Encode many times
because it takes up so much time, others may do likewise.

-- 
andreas

Re: New proposed CPANTS metric: prereq_matches_use

[Matisse Enzer]

On Nov 15, 2007, at 8:04 PM, A. Pagaltzis wrote:


So in order to make everything work robustly, distros should
explicitly list every single module they explicitly use – no
shortcuts, no implications.



basically, I agree completely, with the possible exception of modules  
that are in the Perl core - the standard libraries. On the otehr  
hand, if a specific version of a standard library is required then it  
most certainly should be listed, for example:


  # In Something.pm
  use File::HomeDir 0.66;

and

 # In Makefile.PL
 PREREQ_PM=> { 'File::HomeDir' => '0.66' },

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

* brian d foy <[EMAIL PROTECTED]> [2007-11-15 22:40]:
> If Straps is the only thing that you use, then that's the only
> thing you should list. If Straps has dependencies, it lists
> those.
> 
> Test::Prereq would see what the Straps distro provides and only
> remove those from the prereq list. If Straps doesn't provide
> anything else, it doesn't remove anything else.
> 
> I'm not sure why you think it's some other way.

I don’t know what exactly Test::Prereq does. I checked the docs
but they don’t say precisely how it behaves.

Anyway, irrespective of what ::Prereq does, here’s what I mean:

# found in Something.pm
use Test::Harness;

# found in Other.pm in the same distro
use Test::Harness::Straps;

This distro should list Test::Harness *and* Test::Harness::Straps
as dependencies, even though (at the time of writing) they are
both in the same distro.

Another example:

use Params::Validate;
use Scalar::Util;

This distro should, again, list both Params::Validate *and*
Scalar::Util as prereqs – even though Params::Validate also
depends on Scalar::Util. At some point in the future, P::V
might cease to depend on S::U, but *this* distro will still
depend on it.

So in order to make everything work robustly, distros should
explicitly list every single module they explicitly use – no
shortcuts, no implications.

Regards,
-- 
Aristotle Pagaltzis // 

Re: New proposed CPANTS metric: prereq_matches_use

[brian d foy]

In article <[EMAIL PROTECTED]>, A. Pagaltzis
<[EMAIL PROTECTED]> wrote:

> * brian d foy <[EMAIL PROTECTED]> [2007-11-13 21:10]:
> > In article <[EMAIL PROTECTED]>, David
> > Cantrell <[EMAIL PROTECTED]> wrote:
> > > On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote:
> > 
> > > and:
> > > 
> > > " Foo::Bar is in distribution AUTHOR/Foo-Bar which also
> > >   contains Foo::Bar::Baz, so I only need to declare one of
> > >   them to get both. "
> > > 
> > > This is also an error, as Foo::Bar::Baz might be moved into a
> > > seperate distribution at some point in the future
> > 
> > Well, that's why you check the current distribution to see what
> > it provides. I do this in Test::Prereq.
> 
> Consider Test::Harness::Straps getting released as a separate
> distro recently. Any modules that only use ::Straps but list
> Test::Harness as a prereq will now fail to install. 

If Straps is the only thing that you use, then that's the only thing
you should list. If Straps has dependencies, it lists those.

Test::Prereq would see what the Straps distro provides and only remove
those from the prereq list. If Straps doesn't provide anything else, it
doesn't remove anything else.

I'm not sure why you think it's some other way.

Re: New proposed CPANTS metric: prereq_matches_use

[Matisse Enzer]

On Nov 13, 2007, at 9:19 PM, A. Pagaltzis wrote:


So if you use any module from the CPAN, you should list it
explicitly, not imply it via the main module of its containing
distro.


Yes, exactly.

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

* brian d foy <[EMAIL PROTECTED]> [2007-11-13 21:10]:
> In article <[EMAIL PROTECTED]>, David
> Cantrell <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote:
> 
> > and:
> > 
> > " Foo::Bar is in distribution AUTHOR/Foo-Bar which also
> >   contains Foo::Bar::Baz, so I only need to declare one of
> >   them to get both. "
> > 
> > This is also an error, as Foo::Bar::Baz might be moved into a
> > seperate distribution at some point in the future
> 
> Well, that's why you check the current distribution to see what
> it provides. I do this in Test::Prereq.

Consider Test::Harness::Straps getting released as a separate
distro recently. Any modules that only use ::Straps but list
Test::Harness as a prereq will now fail to install. If ::Straps
were listed as a dependency, installation would continue to Just
Work. So if you use any module from the CPAN, you should list it
explicitly, not imply it via the main module of its containing
distro.

Regards,
-- 
Aristotle Pagaltzis // 

Re: New proposed CPANTS metric: prereq_matches_use

[brian d foy]

In article <[EMAIL PROTECTED]>, David
Cantrell <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote:

> and:
> 
> " Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains
>   Foo::Bar::Baz, so I only need to declare one of them to get both. "
> 
> This is also an error, as Foo::Bar::Baz might be moved into a seperate
> distribution at some point in the future

Well, that's why you check the current distribution to see what it
provides. I do this in Test::Prereq.

Re: New proposed CPANTS metric: prereq_matches_use

[David Cantrell]

On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote:
> * Thomas Klausner <[EMAIL PROTECTED]> [2007-11-12 21:10]:
> > The metric will be called prereq_matches_use and shall check if
> > all the modules used in a dist are also listed as a prereq.
> > (prereq is either gatherd directly from Meta.YMLs 'requires',
> > by parsing Build.PL or Makefile.PL)
> > This results in: Of 12039 dists, 5419 have missing deps
> If a sizable fraction of these are in fact valid hits and not
> just false negatives due to the trickiness of the problem, then
> I would say the metric is direly needed!

I bet most of them are things like:

" I need Foo::Bar and Baz::Barf.  Foo::Bar requires Baz::Barf so I don't
  need to declare it. "

This is an error, because the next version of Foo::Bar might drop that
pre-requisite by, eg, implementing the functionality itself or changing
to use something else.

and:

" Foo::Bar is in distribution AUTHOR/Foo-Bar which also contains
  Foo::Bar::Baz, so I only need to declare one of them to get both. "

This is also an error, as Foo::Bar::Baz might be moved into a seperate
distribution at some point in the future, or its functionality might be
folded into Foo::Bar.

I approve of this kwalitee metric and would like to subscribe to its
newsletter^W^W^W^Wbe told which of my modules are broken.

-- 
David Cantrell | top google result for "internet beard fetish club"

One person can change the world, but most of the time they shouldn't
-- Marge Simpson

Re: New proposed CPANTS metric: prereq_matches_use

[Andreas J. Koenig]

> On Tue, 13 Nov 2007 02:08:41 +0100, Sébastien Aperghis-Tramoni <[EMAIL 
> PROTECTED]> said:

  > There was already a module that does this, I can't remember it's name,

Maybe B::Prereq and its companion Test::Dependencies.

-- 
andreas

Re: New proposed CPANTS metric: prereq_matches_use

[Adrian Howard]

On 13 Nov 2007, at 04:29, Geoffrey Young wrote:



The metric will be called prereq_matches_use and shall check if  
all the

modules used in a dist are also listed as a prereq.


I find this odd.

if I check a prereq for mod_perl (.pm) I know I have the 50 some  
modules
that come with a mod_perl distribution.  check for LWP and I know I  
have

HTTP::Request.  I'm sure the list goes on.


While I can accept it's a place where reasonable folk can differ I  
prefer it where each module is mentioned rather than each  
distribution. It helps when I'm having to deal with "interesting"  
installations where people have managed to get different bits of an  
installation in different places.


However, I suspect that enough folk are of the opposite opinion that  
a CPANTS metric wouldn't be very useful :-)


Adrian

Re: New proposed CPANTS metric: prereq_matches_use

[Geoffrey Young]

> The metric will be called prereq_matches_use and shall check if all the 
> modules used in a dist are also listed as a prereq.

I find this odd.

if I check a prereq for mod_perl (.pm) I know I have the 50 some modules
that come with a mod_perl distribution.  check for LWP and I know I have
HTTP::Request.  I'm sure the list goes on.

--Geoff
(who admittedly doesn't really buy into kwalitee metrics anyway :)

Re: New proposed CPANTS metric: prereq_matches_use

[Sébastien Aperghis-Tramoni]

Thomas Klausner wrote:


I'm currently thinking about a new CPANTS metric (and I even have a
half-finished implementation..), and I'd like to get some feedback on
it, before spending more time on it (or even releasing it..)

The metric will be called prereq_matches_use and shall check if all  
the

modules used in a dist are also listed as a prereq. (prereq is either
gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or
Makefile.PL)

As you might know this is quite tricky, because some modules live in
strange dists (e.g. HTTP::Request -> libwww-perl)


There was already a module that does this, I can't remember it's  
name, and it insisted that each module after a use was listed in  
PREREQ_PM, which was quite bothersome because it wanted both LWP and  
HTTP::Request to be listed for example.



and some modules are in Core (I'll check this with Module::CoreList).


Each time I here "checking with Module::CoreList", I wonder which  
version will be tested against.



[...]
What do you think?


+1 for the rest

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

Hi Thomas,

* Thomas Klausner <[EMAIL PROTECTED]> [2007-11-12 21:10]:
> The metric will be called prereq_matches_use and shall check if
> all the modules used in a dist are also listed as a prereq.
> (prereq is either gatherd directly from Meta.YMLs 'requires',
> by parsing Build.PL or Makefile.PL)

sounds great to me.

> This results in: Of 12039 dists, 5419 have missing deps

If a sizable fraction of these are in fact valid hits and not
just false negatives due to the trickiness of the problem, then
I would say the metric is direly needed!

> Adiitionally, there is a lot of potential finetuning possible:
> 
> - do not award the kwalitee point if there are too many listed
>   prereqs (i.e. the dist requires another dist, without
>   actually using it.) This might be controversial, because
>   authors could lists dists as a prereq which are a prereq of a
>   prereq (etc) - for various valid (?) reasons...

-1. At most this should be an optional metric, but even then it’s
likely as not to be harmful.

> - also check build_requires (I'm not sure if other buildtools
>   than Module::Build support this), with this twist: If dists
>   are only used in tests, but are listed in 'requires', do not
>   award a kwalitee point.

+1

Regards,
-- 
Aristotle Pagaltzis // 

Re: New proposed CPANTS metric: prereq_matches_use

[Eric Wilhelm]

# from Thomas Klausner
# on Monday 12 November 2007 12:05:

> check if all the modules used in a dist are also listed as a prereq
> ... by parsing Build.PL or Makefile.PL

How do you propose to address system-dependent requirements?  (e.g. "$^O 
eq 'MSWin32'" issues.)  If you do not execute the Makefile.PL/Build.PL, 
you do not know whether you are working from the correct list of 
requisites.

>As you might know this is quite tricky, because some modules live in
>strange dists (e.g. HTTP::Request -> libwww-perl) and some modules are
> in Core (I'll check this with Module::CoreList).

And some modules spring into existence at compile time with 
Package::Tent :-D

Are you planning to implement this with parsing or compiling the code?

I would love to see something like "run the test suite under 
Devel::TraceLoad" and compare to the prereq list.

But that is probably a better author tool than a kwalitee metric, 
especially if the kwalitee metric is wrong.

How about asking the author if they ran such a thing (e.g. checking 
META.yml for a "yes, I did indeed run checkrequires before rolling this 
dist" flag?)

In other words: how the metrics has_pod_test and has_pod_coverage_test 
should have been done in the first place.

--Eric
-- 
Cult: A small, unpopular religion.
Religion: A large, popular cult.
-- Unknown
---
http://scratchcomputing.com
---

New proposed CPANTS metric: prereq_matches_use

[Thomas Klausner]

Hi!

I'm currently thinking about a new CPANTS metric (and I even have a 
half-finished implementation..), and I'd like to get some feedback on 
it, before spending more time on it (or even releasing it..)

The metric will be called prereq_matches_use and shall check if all the 
modules used in a dist are also listed as a prereq. (prereq is either 
gatherd directly from Meta.YMLs 'requires', by parsing Build.PL or 
Makefile.PL)

As you might know this is quite tricky, because some modules live in 
strange dists (e.g. HTTP::Request -> libwww-perl) and some modules are in 
Core (I'll check this with Module::CoreList).

The first implementation 'simply' selects all distinct dists from all 
modules (of which CPANTS know which dist they are in..) used in a dist, 
and compares this with the distinct dists from all listed prereqs.

This results in: Of 12039 dists, 5419 have missing deps

Adiitionally, there is a lot of potential finetuning possible:

- do not award the kwalitee point if there are too many listed prereqs 
  (i.e. the dist requires another dist, without actually using it.)
  This might be controversial, because authors could lists dists as a 
  prereq which are a prereq of a prereq (etc) - for various valid (?) 
  reasons...

- also check build_requires (I'm not sure if other buildtools than 
  Module::Build support this), with this twist:
  If dists are only used in tests, but are listed in 'requires', do not 
  award a kwalitee point.

What do you think?


-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[David Cantrell]

Jonathan Rockway wrote:


You might like File::ShareDir for this.  That way you can keep the big
data file out of band, and avoid having to maintain a database inside
your perl file.


Unfortunately it requires Module::Install.

--
David Cantrell

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[Jonathan Rockway]

David Cantrell wrote:
> Number::Phone::UK::Data contains a big chunk of binary gibberish at
> the end of the file (it's an embedded DBM::Deep database), in a
> __DATA__ segment.  That includes several "lines" that match /^=/ and
> so might look like POD, and hence confuse things.  I'd argue that this
> means there's a bug in Pod::Simple::Checker and/or Test::Pod, if
> they're looking at stuff in __DATA__.


You might like File::ShareDir for this.  That way you can keep the big
data file out of band, and avoid having to maintain a database inside
your perl file.

Regards,
Jonathan Rockway




signature.asc
Description: OpenPGP digital signature

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[brian d foy]

In article <[EMAIL PROTECTED]>, David Cantrell
<[EMAIL PROTECTED]> wrote:


> Number::Phone::UK::Data contains a big chunk of binary gibberish at the 
> end of the file (it's an embedded DBM::Deep database), in a __DATA__ 
> segment.  That includes several "lines" that match /^=/ and so might 
> look like POD, and hence confuse things.  I'd argue that this means 
> there's a bug in Pod::Simple::Checker and/or Test::Pod, if they're 
> looking at stuff in __DATA__.

Well, there are lots of problems with Pod::Simple::Checker because it
doesn't do stuff to figure out where it is. I've had to turn off
Test::Pod in a couple modules for that reason.

Curiously, I think Perl 6's current Pod spec is going to have the same
problem.  Any line that starts with a = currently triggers Pod mode, no
matter what is going on.

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[David Cantrell]

Hrrm, I never saw my reply to Thomas's message - looks like it got eaten 
by something.  My apologies if this is a repeat for you ...


Thomas Klausner wrote:


Some dists (eg Number::Phone)


Urk, that's one of mine.

>currently cause segfaults in cpants

Sorry!

I tracked the problem down to this: Pod::Simple::Checker (and Test::Pod) 
report very strange things when run against eg. Number::Phone.


Number::Phone::UK::Data contains a big chunk of binary gibberish at the 
end of the file (it's an embedded DBM::Deep database), in a __DATA__ 
segment.  That includes several "lines" that match /^=/ and so might 
look like POD, and hence confuse things.  I'd argue that this means 
there's a bug in Pod::Simple::Checker and/or Test::Pod, if they're 
looking at stuff in __DATA__.


It may be significant that the __DATA__ marker isn't at column zero, so 
if the parser is looking for /^__DATA__/ that would explain why it's not 
spotted.


Number-Phone-UK-DetailedLocations will probably make things go boom for 
the same reason.


BTW, adding a run-of-the-mill pod.t to Number-Phone also yields some 
interesting results (loads of garbage output)


Yeah, and for the same reason.

--
David Cantrell

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[Andreas J. Koenig]

> On Thu, 13 Sep 2007 20:45:38 +0200, Thomas Klausner <[EMAIL PROTECTED]> 
> said:

  > perl -MYAML=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'

Use YAML::Syck! It will cut your execution time too. Significantly!

% time perl -MYAML::Syck=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'
perl -MYAML::Syck=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")' 0,04s user 
0,00s system 95% cpu 0,042 total



-- 
andreas

Re: Test::Pod / YAML explodes (and taking cpants with it...)

[Michael G Schwern]

Thomas Klausner wrote:
> I'm not sure if the problem is caused by some dists liek Number::Phone, 
> or by Pod::Simple::Checker (YAML for sure is causing the segfaults, but 
> I'd definitly want to correct the data, too)
> 
> I've put one of the problematic files up here:
> http://cpants.perl.org/static/Number-Phone-1.58.yml
> (look for the line starting with 'pod_errors_msg')
> 
> To see YAML expolode, try:
> perl -MYAML=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'
> 
> I'm currently working on a hackish workaround, but I think this might be 
> a bug somewhere that's worth squashing. Now I (or we) only need to 
> figure out where the problem lies.

Use YAML::Syck instead?  It's faster, it handles that noise just fine.


-- 
Robrt:   People can't win
Schwern: No, but they can riot after the game.

Test::Pod / YAML explodes (and taking cpants with it...)

[Thomas Klausner]

Hi!

You might wonder why cpants.perl.org is still down, even though I found 
some time to work on it.

Here's why:

Some dists (eg Number::Phone) currently cause segfaults in cpants [Meta: 
I changed a few things in how cpants processes CPAN. In a first pass, 
cpants writes a YAML file for each dist  containing all the info. In the 
second pass, the YAML files are read and stored into the DB)

I tracked the problem down to this: Pod::Simple::Checker (and Test::Pod) 
report very strange things when run against eg. Number::Phone. This 
semi-garbage is then stored in a yaml file. Which works. But during the 
second pass, YAML doesn't eat it's own dog food and segfaults while 
parsing the yaml.

I'm not sure if the problem is caused by some dists liek Number::Phone, 
or by Pod::Simple::Checker (YAML for sure is causing the segfaults, but 
I'd definitly want to correct the data, too)

I've put one of the problematic files up here:
http://cpants.perl.org/static/Number-Phone-1.58.yml
(look for the line starting with 'pod_errors_msg')

To see YAML expolode, try:
perl -MYAML=LoadFile -le 'LoadFile("Number-Phone-1.58.yml")'

I'm currently working on a hackish workaround, but I think this might be 
a bug somewhere that's worth squashing. Now I (or we) only need to 
figure out where the problem lies.

BTW, adding a run-of-the-mill pod.t to Number-Phone also yields some 
interesting results (loads of garbage output)

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: cpants not updating; new cpants test request

[Michael G Schwern]

Thomas Klausner wrote:
> On Mon, Sep 10, 2007 at 11:10:25PM +0200, Anonymous wrote:
>  
>> also, would it make sense to have a test to check for warnings
>> when warnings are enabled globally? many modules do not enable
>> warnings, but when you use those modules and run the script
>> with -w, it's possible to get lots of warnings.
> 
> There was a use_warnings metric (similar to use_strict), but a lot of 
> people said that was too strict, so I removed it. It might make sense to 
> re-add this metric as an optional kwalitee point, though (which weren't 
> implemented then...)

I was thinking "but that's prejudiced against 5.005 code" but now we have
warnings::compat so that's largely moot.

FWIW  I turn on my warnings in the tests, not the modules.


-- 
Stabbing you in the face for your own good.

Re: cpants not updating; new cpants test request

[Andy Armstrong]

On 11 Sep 2007, at 21:12, Thomas Klausner wrote:

Oh sorry Thomas - I assumed it was me. Shall I turn it off again?


Hm, I guess it's better to turn it off.


OK - it's turned off again for the moment.

--
Andy Armstrong, hexten.net

Re: cpants not updating; new cpants test request

[Thomas Klausner]

Hi!

On Tue, Sep 11, 2007 at 08:39:57PM +0100, Andy Armstrong wrote:
> On 11 Sep 2007, at 20:37, Thomas Klausner wrote:
> >On Tue, Sep 11, 2007 at 01:43:43PM +0100, Andy Armstrong wrote:
> >>On 10 Sep 2007, at 22:10, Anonymous wrote:
> >>>looks like the cpants site has stopped updating for about 3
> >>>weeks now.
> >>
> >>Oops. That's my fault. cron job now re-enabled. Blush.
> >
> >No, that was my fault, as I turned it off.
> 
> Oh sorry Thomas - I assumed it was me. Shall I turn it off again?

Hm, I guess it's better to turn it off.

> >CPANTS has a bug at the moment, and due to YAPC (and post-YAPC work
> >overload etc) I haven't found time yet to fix it.
> 
> But you and the team made YAPC look s easy :)

Well, thanks, but there was some work involved :-)

Add this to the fact that I was more than a month in Mongolia prior to 
YAPC, and you can start to gauge how much @work I have to handle. But 
now I'll stop complaining and JFDI

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: cpants not updating; new cpants test request

[Andy Armstrong]

On 11 Sep 2007, at 20:37, Thomas Klausner wrote:

On Tue, Sep 11, 2007 at 01:43:43PM +0100, Andy Armstrong wrote:

On 10 Sep 2007, at 22:10, Anonymous wrote:

looks like the cpants site has stopped updating for about 3
weeks now.


Oops. That's my fault. cron job now re-enabled. Blush.


No, that was my fault, as I turned it off.


Oh sorry Thomas - I assumed it was me. Shall I turn it off again?


CPANTS has a bug at the moment, and due to YAPC (and post-YAPC work
overload etc) I haven't found time yet to fix it.


But you and the team made YAPC look s easy :)

--
Andy Armstrong, hexten.net

Re: cpants not updating; new cpants test request

[Thomas Klausner]

Hi!

On Mon, Sep 10, 2007 at 11:10:25PM +0200, Anonymous wrote:
 
> also, would it make sense to have a test to check for warnings
> when warnings are enabled globally? many modules do not enable
> warnings, but when you use those modules and run the script
> with -w, it's possible to get lots of warnings.

There was a use_warnings metric (similar to use_strict), but a lot of 
people said that was too strict, so I removed it. It might make sense to 
re-add this metric as an optional kwalitee point, though (which weren't 
implemented then...)

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: cpants not updating; new cpants test request

[Thomas Klausner]

Hi!

On Tue, Sep 11, 2007 at 01:43:43PM +0100, Andy Armstrong wrote:
> On 10 Sep 2007, at 22:10, Anonymous wrote:
> >looks like the cpants site has stopped updating for about 3
> >weeks now.
> 
> Oops. That's my fault. cron job now re-enabled. Blush.

No, that was my fault, as I turned it off.

CPANTS has a bug at the moment, and due to YAPC (and post-YAPC work 
overload etc) I haven't found time yet to fix it.

But I'll try to find some time this week (maybe tomorrow, maybe Friday).


-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: cpants not updating; new cpants test request

[Andy Armstrong]

On 10 Sep 2007, at 22:10, Anonymous wrote:

looks like the cpants site has stopped updating for about 3
weeks now.


Oops. That's my fault. cron job now re-enabled. Blush.

--
Andy Armstrong, hexten.net

cpants not updating; new cpants test request

[Anonymous]

looks like the cpants site has stopped updating for about 3
weeks now.

also, would it make sense to have a test to check for warnings
when warnings are enabled globally? many modules do not enable
warnings, but when you use those modules and run the script
with -w, it's possible to get lots of warnings.

Re: CPANTS: suggestion for a new metric

[chromatic]

On Saturday 02 June 2007 03:33:27 Nathan S. Haigh wrote:

> On my return from holiday, who am I best sending my changes to?

The RT queue for Test::Kwalitee please, where I won't lose them.

-- c

Re: CPANTS: suggestion for a new metric

[Andy Armstrong]

On 2 Jun 2007, at 11:33, Nathan S. Haigh wrote:

On my return from holiday, who am I best sending my changes to?


You could certainly send them to me. Maybe put them on rt.cpan.org too?

--
Andy Armstrong, hexten.net

Re: CPANTS: suggestion for a new metric

[Nathan S. Haigh]

Quoting brian d foy <[EMAIL PROTECTED]>:

> In article <[EMAIL PROTECTED]>, Nathan S.
> Haigh <[EMAIL PROTECTED]> wrote:
> 
> >  A suggestion was to have different levels of
> > "strictness" in Test::Kwalitee and have different sets of metrics being
> > tested by
> > default at each of those levels. However, I didn´t get into this and simply
> > hard-coded some of the metrics to be skipped.
> 
> I think that's a bit out of Test::Kwalitee's scope. It basically wraps
> each of the metric code refs in the testing framework and provides
> access to those things individually. It's then up to the user to decide
> which functions he wants to use.  
> 
> I'd leave Test::Kwalitee just like it is, feature-wise, and not have it
> dictate use or practice. Let it just provide the ability. Sub-classes
> and user classes, which probably have a much better chance of being
> maintained, should be the way to go.
> 
> That's just my two cents though, and I'm willing to help clear out the
> current issues no matter which way it goes.
> 


I agree, however, should an update be backward compatible or not? I mean, is it 
reasonable for someone to update their Test::Kwalitee module and then
have them rewrite their tests such that they skip all tests that require a tar 
ball of their package etc? These are hard-coded to be skipped in the
current version of Test::Kwalitee. This was one of the reasons I also hardcoded 
some metrics to be skipped. I´m pretty new to writing modules and
tests, so I´m at your mercy with regards to best practices, but I too think 
that Test::Kwalitee should be able to test all metrics and it should be
left to the user to decide which, if any metrics should be skipped. This could 
be easily changed in my existing patch to the current Test::Kwalitee
module. It would have the ame behaviour as the current version for skipping 
metrics i.e.:

Test::Kwalitee->import( tests => [ qw( -has_test_pod -has_test_pod_coverage ) ] 
)

On my return from holiday, who am I best sending my changes to?

Nathan

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[brian d foy]

In article <[EMAIL PROTECTED]>, chromatic
<[EMAIL PROTECTED]> wrote:

> On Friday 01 June 2007 10:47:00 Andy Armstrong wrote:
> 
> > You could send them to me if you fancy? I'm guessing chromatic's
> > pretty busy.
> 
> I lost most of my outstanding patches a couple of weeks ago too, and only
> just 
> noticed.

If only we had some sort of community service where we could post
patches and other people could see them :)

Re: CPANTS: suggestion for a new metric

[brian d foy]

In article <[EMAIL PROTECTED]>, Nathan S.
Haigh <[EMAIL PROTECTED]> wrote:

>  A suggestion was to have different levels of
> "strictness" in Test::Kwalitee and have different sets of metrics being
> tested by
> default at each of those levels. However, I didn´t get into this and simply
> hard-coded some of the metrics to be skipped.

I think that's a bit out of Test::Kwalitee's scope. It basically wraps
each of the metric code refs in the testing framework and provides
access to those things individually. It's then up to the user to decide
which functions he wants to use.  

I'd leave Test::Kwalitee just like it is, feature-wise, and not have it
dictate use or practice. Let it just provide the ability. Sub-classes
and user classes, which probably have a much better chance of being
maintained, should be the way to go.

That's just my two cents though, and I'm willing to help clear out the
current issues no matter which way it goes.

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-02 03:40]:
> I know it's not as cute as the current interface - but cute can
> be surprising and I don't think a surprising interface is
> necessarily a  good thing :)

Agreed. It just depended on what you preferred; in case of a
method per metric, generating methods + AUTOLOAD seemed to me to
be the simplest option, as it would involve the least amount of
conditional code.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 2 Jun 2007, at 01:25, A. Pagaltzis wrote:


* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-01 16:25]:

I could

* generate the methods dynamically based on the Kwalitee
  modules that are installed

* generate only the current methods and add a new method
  test_against() (or whatever) that provides access to any
  named Kwalitee test

* replace the generated methods with an AUTOLOAD handler

In the test_against() or AUTOLOAD scenarios I could then make
Kwalitee tests for which the module is unavailable skip
automatically.

Thoughts?


Remember you can also combine options #1 and #3: generate methods
at compile-time and use AUTOLOAD just for skipping. Would there
be any provision for catching typos in any of these cases,
though?


Well no. And that's one of the reasons why I'd like to move away from  
the method-named-after-test interface entirely. I'm thinking


* create the same methods that are currently created - for backwards  
compatibility

* deprecate that interface
* create a new interface - kwalitee('test_name', ...) which is just a  
conventional method that despatches to the

  named test.

I know it's not as cute as the current interface - but cute can be  
surprising and I don't think a surprising interface is necessarily a  
good thing :)


--
Andy Armstrong, hexten.net

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-01 16:25]:
> I could
> 
> * generate the methods dynamically based on the Kwalitee
>   modules that are installed
> 
> * generate only the current methods and add a new method
>   test_against() (or whatever) that provides access to any
>   named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make
> Kwalitee tests for which the module is unavailable skip
> automatically.
> 
> Thoughts?

Remember you can also combine options #1 and #3: generate methods
at compile-time and use AUTOLOAD just for skipping. Would there
be any provision for catching typos in any of these cases,
though?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[chromatic]

On Friday 01 June 2007 10:47:00 Andy Armstrong wrote:

> You could send them to me if you fancy? I'm guessing chromatic's
> pretty busy.

I lost most of my outstanding patches a couple of weeks ago too, and only just 
noticed.

-- c

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Thomas Klausner]

Hi!

On Fri, Jun 01, 2007 at 03:23:14PM +0100, Andy Armstrong wrote:
 
> Test::Kwalitee currently exposes the known test types as methods. I can
> make it delve into Module::CPANTS::Analyse to find the tests that are
> actually available - but then what to do about the methods?

Sorry, not a lot of time at the momemt, but I remember that somebody 
(I think  Nathan Haigh <[EMAIL PROTECTED]> ) already patched 
Test::Kwalitee to dynamically figure out which metric to use.

But I'm only following this thread with 50% attention (sorry, YAPC takes 
up all my tuits ATM), so might mix up things...


> I could
> 
> * generate the methods dynamically based on the Kwalitee modules that
>   are installed
> 
> * generate only the current methods and add a new method test_against()
>   (or whatever) that provides access to any named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
> tests for which the module is unavailable skip automatically.
> 
> Thoughts?
> 
> -- 
> Andy Armstrong, hexten.net
> 

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: CPANTS: suggestion for a new metric

[Nathan S. Haigh]

Quoting brian d foy <[EMAIL PROTECTED]>:

> On 5/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> > On 31 May 2007, at 21:42, brian d foy wrote:
> > > I've just been running cpants_lint.pl before I upload anything. If it
> > > doesn't say "perfect", that fails. :)
> >
> > Yes, damn you :)
> >
> > I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't
> > need too much.
> 
> I looked at the RT tickets. I think three of them can be closed
> immediately or re-assigned to Module::CPANTS::Analyse. Test::Kwalitee
> just does wraps taht module, so if people don't like how it does the
> work, it's not Test::Kwalitee's problem.
> 
> One is a documentation patch, which is easy.
> 
> The rest of them can probably be cleaned up by peeking into
> Module::CPANTS::Analyse to get the names and descriptions of the tests
> to build the %test_types hash in Test::Kwalitee. I think that's the
> only thing that needs an update. I think
> Module::CPANTS::Kwalitee->new->get_indicators_hash should take care of
> that.
> 

I already did this and sent Chromatic the changes, but he hasn´t yet got round 
to putting the changes on CPAN. One of the issues was that some metrics
are for testing the tar ball which usually doesn´t make sense in a normal 
testing environment. In addition, thare are some other metrics which could
be deemed "optioanl". A suggestion was to have different levels of "strictness" 
in Test::Kwalitee and have different sets of metrics being tested by
default at each of those levels. However, I didn´t get into this and simply 
hard-coded some of the metrics to be skipped.

Nathan


> I'll have some time next week if Andy doesn't beat me too it.
> 
> 
> -- 
> brian d foy <[EMAIL PROTECTED]>
> http://www.pair.com/~comdog/
> 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 1 Jun 2007, at 18:41, Nathan S. Haigh wrote:
I recently made some simple changes to Test::Kwalitee so that it  
would test all the metrics provided by Module::CPANTS::Analyse.  
However, Chromitic
hasn´t yet updated CPAN with these changes. I´m on holiday at the  
moment so I won´t be even more nerdy than I am at the moment ) 
reading my works
e-mails) by going into detail about the changes. Either Chromictic  
could get the changes through into CPAN or I can send you my  
changes on my return

from holiday!


You could send them to me if you fancy? I'm guessing chromatic's  
pretty busy.


--
Andy Armstrong, hexten.net

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Nathan S. Haigh]

Quoting Andy Armstrong <[EMAIL PROTECTED]>:

> On 1 Jun 2007, at 06:38, chromatic wrote:
> 
> > On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote:
> >> On 1 Jun 2007, at 02:09, brian d foy wrote:
> >>> I'll have some time next week if Andy doesn't beat me too it.
> >>
> >> I'm having a rummage around now :)
> >>
> >> chromatic: do you have a .perltidyrc you could send me? My muscle
> >> memory keeps reaching for the perltidy hot key that would convert
> >> your code to AndyPerl :)
> >
> > I use -ci=4 -bl these days.
> 
> Not on Test::Kwalitee you didn't :)
> 
> What's peoples' view on this?
> 
> Test::Kwalitee currently exposes the known test types as methods. I can
> make it delve into Module::CPANTS::Analyse to find the tests that are
> actually available - but then what to do about the methods?
> 
> I could
> 
> * generate the methods dynamically based on the Kwalitee modules that
>are installed
> 
> * generate only the current methods and add a new method test_against()
>(or whatever) that provides access to any named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
> tests for which the module is unavailable skip automatically.
> 
> Thoughts?
> 
> -- 
> Andy Armstrong, hexten.net
> 
> 


I recently made some simple changes to Test::Kwalitee so that it would test all 
the metrics provided by Module::CPANTS::Analyse. However, Chromitic
hasn´t yet updated CPAN with these changes. I´m on holiday at the moment so I 
won´t be even more nerdy than I am at the moment )reading my works
e-mails) by going into detail about the changes. Either Chromictic could get 
the changes through into CPAN or I can send you my changes on my return
from holiday!

Cheers
Nathan

Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[Andy Armstrong]

On 1 Jun 2007, at 06:38, chromatic wrote:


On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote:

On 1 Jun 2007, at 02:09, brian d foy wrote:

I'll have some time next week if Andy doesn't beat me too it.


I'm having a rummage around now :)

chromatic: do you have a .perltidyrc you could send me? My muscle
memory keeps reaching for the perltidy hot key that would convert
your code to AndyPerl :)


I use -ci=4 -bl these days.


Not on Test::Kwalitee you didn't :)

What's peoples' view on this?

Test::Kwalitee currently exposes the known test types as methods. I can
make it delve into Module::CPANTS::Analyse to find the tests that are
actually available - but then what to do about the methods?

I could

* generate the methods dynamically based on the Kwalitee modules that
  are installed

* generate only the current methods and add a new method test_against()
  (or whatever) that provides access to any named Kwalitee test

* replace the generated methods with an AUTOLOAD handler

In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
tests for which the module is unavailable skip automatically.

Thoughts?

--
Andy Armstrong, hexten.net

Re: CPANTS: suggestion for a new metric

[chromatic]

On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote:
> On 1 Jun 2007, at 02:09, brian d foy wrote:
> > I'll have some time next week if Andy doesn't beat me too it.
>
> I'm having a rummage around now :)
>
> chromatic: do you have a .perltidyrc you could send me? My muscle
> memory keeps reaching for the perltidy hot key that would convert
> your code to AndyPerl :)

I use -ci=4 -bl these days.

-- c

Re: CPANTS reports in e-mail

[Chris Dolan]

On May 31, 2007, at 2:28 AM, Eric Wilhelm wrote:

And for the rest of us to stay current, maybe a low-volume mailing  
list

solely for notifications of various new/changed perl/cpan services?


Posting to module-authors should be fine if it's low volume.  No need  
for yet another mailing list ("yaml" is already taken)


Chris

--
Chris Dolan, Equilibrious LLC, http://equilibrious.net/
Public key: http://chrisdolan.net/public.key
vCard: http://chrisdolan.net/ChrisDolan.vcf

Re: CPANTS: suggestion for a new metric

[Andy Armstrong]

On 1 Jun 2007, at 02:09, brian d foy wrote:

I'll have some time next week if Andy doesn't beat me too it.


I'm having a rummage around now :)

chromatic: do you have a .perltidyrc you could send me? My muscle  
memory keeps reaching for the perltidy hot key that would convert  
your code to AndyPerl :)


--
Andy Armstrong, hexten.net

Re: CPANTS: suggestion for a new metric

[brian d foy]

On 5/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:

On 31 May 2007, at 21:42, brian d foy wrote:
> I've just been running cpants_lint.pl before I upload anything. If it
> doesn't say "perfect", that fails. :)

Yes, damn you :)

I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't
need too much.


I looked at the RT tickets. I think three of them can be closed
immediately or re-assigned to Module::CPANTS::Analyse. Test::Kwalitee
just does wraps taht module, so if people don't like how it does the
work, it's not Test::Kwalitee's problem.

One is a documentation patch, which is easy.

The rest of them can probably be cleaned up by peeking into
Module::CPANTS::Analyse to get the names and descriptions of the tests
to build the %test_types hash in Test::Kwalitee. I think that's the
only thing that needs an update. I think
Module::CPANTS::Kwalitee->new->get_indicators_hash should take care of
that.

I'll have some time next week if Andy doesn't beat me too it.


--
brian d foy <[EMAIL PROTECTED]>
http://www.pair.com/~comdog/

Re: CPANTS: suggestion for a new metric

[Andy Armstrong]

On 31 May 2007, at 21:42, brian d foy wrote:

I've just been running cpants_lint.pl before I upload anything. If it
doesn't say "perfect", that fails. :)


Yes, damn you :)

I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't  
need too much.


--
Andy Armstrong, hexten.net

Re: CPANTS: suggestion for a new metric

[brian d foy]

[[ This message was both posted and mailed: see
   the "To," "Cc," and "Newsgroups" headers for details. ]]

In article <[EMAIL PROTECTED]>, chromatic
<[EMAIL PROTECTED]> wrote:

> On Wednesday 30 May 2007 14:54:27 demerphq wrote:
> 
> > Er, so you want a metric to tell people about how their rejected
> > upload to PAUSE isnt going to work right?
> >
> > That doesnt sound like a very useful metric. If PAUSE doesnt index it
> > then you shouldnt test it as its already failed the most important
> > metric there is.
> 
> If I had time to fix Test::Kwalitee, you could run that test *before* 
> uploading a distribution to PAUSE, or on DarkPAN code.  Not all of CPANTS has 
> to run against publicly-uploaded distributions.

What does Test::Kwalitee need? Is it just fixing the stuff in RT or is
there something else?

I've just been running cpants_lint.pl before I upload anything. If it
doesn't say "perfect", that fails. :)

Re: CPANTS reports in e-mail

[Shlomi Fish]

On Thursday 31 May 2007, Andy Armstrong wrote:
> On 31 May 2007, at 08:28, Eric Wilhelm wrote:
> > Wouldn't it would be interesting if there were a multiplexing service
> > for this sort of thing?  E.g. maybe a system that allows you to
> > subscribe to a personal mailing list of sorts in much the same way
> > that
> > you can get an rss feed for a given rt query.  Cue debate over push vs
> > pull.
>
> I'm sure RSS is the way to go - at least as an option. No problem
> with opting in / opting out / loosing stuff in their spam filter.

Sounds good to me, although an email feature will also be nice (though there's 
always rss2email or a different RSS to email gateway).

I should note that like Gabor said I'd like this feature to be opt-in, because 
I don't want it. I don't care too much about the CPANTS so-called "kwalitee", 
although sometimes when I'm bored, I raise the kwalitee of some of my 
modules. Still, I see it as just a silly game, and not really an indication 
of quality.

But Gabor's idea is good.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer

Re: CPANTS reports in e-mail

[Ian Malpass]

Gabor Szabo wrote:


The question remaining for me is how to notify module authors who don't yet
know about CPANTS? Oh, I guess you will say if someone wants to
know on how to make his module better will find the resources
including the modul-authors list and CPANTS.


How about putting notes and a link in LARGE FRIENDLY LETTERS on the 
PAUSE web site, so authors get the message when they upload their next 
release?


Ian