use Perl

I agree in full. It's like, "Here, let's declare our deps in this file, except for the secret ones that we assume!"

With Perl 5 that would look like either:

package POC::TestAnnouncer;

use Moose::Role;

before test => sub {
  my $project = $_[1];
  announce-start-of('test', $project{name});
};

after test => sub {
  my $project = $_[1];
  announce-end-of('test', $project{name});
};

And then there's the more powerful around:

package POC::TestAnnouncer;

use Moose::Role;

around test => sub {
  my $fn = shift;
  my $self = shift;
  my $project = $_[0];
  announce-start-of('test', $project{name});
  my $ret = $self->$fn(@_);
  announce-end-of('test', $project{name});
  return $ret
};

The former is probably preferred because you don't have to worry about calling the original method; of course you can't munge arguments with the former, but that's a feature.

I wonder which would be easier, fixing it to use TAP or just porting it to perl? The latter might be nice because I don't really want to learn how python installing works etc.

Well, it's probably not always possible to get 100% coverage, but if a single test gets 100% coverage (possible with simple modules) I don't think that it should lose points.

On the other hand I recently adopted a module on CPAN that originally just had basic use tests and some autogenerated pod tests. It didn't test the basic functionality AT ALL. It always passed tests on all platforms, but that's because it didn't have any real tests. I'd say that it should have gotten a low ranking for something like this.

Maybe a reasonable compromise would be to find the average coverage (I'd guess somewhere in the high 80's to low 90's) and say if you are above that then it no longer measures cov.

Lastly, it would probably be best to make this as multiweighted as possible so it's hard to game without just making a good module :-)

Arguably the best metric wouldn't be amount of tests/passing tests, but the coverage of passing tests. That would certainly be slow, but it would work best.

That's probably not yet possible with rakudo, but it will certainly work eventually.

Agreed. There are times when you need a plan for sure (my current project for example, where I test for lots of different types of exceptions) but in general I find it thought cruft. Also note that no_plan doesn't (I think) detect die'ing halfway through.

It seems like you got what flash and stash are backwards, from the docs in the Session plugin. You say flash lasts for one request. This is what the doc for it says:

"Think of it as a stash that lasts for longer than one request, letting you redirect instead of forward."

Am I misunderstanding?

I agree that posts with content are a form of marketing, and this one that I am commenting on is fine as it points at a useful module. It's just all the meta about how we need a marketer that bothers me. I'm fine when people talk about that and pursue hiring a marketer or whatever, but just talk about marketing is, at least to me, not helpful.

With perl, a coderef is a subroutine, basically.  With rubies coderefs, they are more like perl's blocks:

use feature ':5.10';
sub foo {
   say 'beginning of foo';
   bar();
   say 'ending of foo';
}

sub bar {
   say 'beginning of bar';
   my @foo = grep { return } (1,2,3,4); # I'd say this should mean none
   say 'ending of bar';
}

foo();

Note that the grep kills bar.

You could easily pull it off with an error match. I have a few of those on my after\ftplugin\javascript.vim, for guarding against things like trailing commas and whatnot. Here's mine:

match Error /,\_s*[)\]}]\|[:,][^ ]\|\\|\\|[^0]\.[0-9]\+\|=\@!===\@!\|!==\@!/

I'd say make it monthly. Especially if their module isn't failing, but you didn't make it clear if you meant always or just when it was failing.

You could also consider writing a backend server that your frontend talks to with TCP/IP. I did this with IO::All so that I could have a perlcritic backend that doesn't slow down my client so much.

see footer

Check it out

I'd like to do it again some time for sure. There is a lot of interesting code in the setting the deserves to be read. I looked a lot more at the nuts and bolts of the code instead of the overall structure like you did, but mostly because I still need to grok perl6.

I think this is an excellent idea! I tried to do a little of it myself with some Setting code, but it was something like 25 lines, so nowhere near what you are doing, but hey; it's a start!