Re: todo tests in the TAP Plan
On 8 Sep 2006, at 01:52, Michael G Schwern wrote: Adrian Howard wrote: Maybe this is the right time to think about mechanisms supporting different versions of the TAP protocol? http://perl-qa.yi.org/index.php/TAP_version I meant in the context of Ovid's TAPx::Parser code. Rather than adding the old style Test.pm syntax to the existing parser, have an old and a current parser. Adrian
TAPx::Parser 0.21
Changes: 0.21 8 September 2006 - Included experimental GTK interface written by Torsten Schoenfeld. - Fixed bad docs in examples/tprove_color - Applied patch from Shlomi Fish fixing bug where runs from one stream could leak into another when bailing out. [rt.cpan.org #21379] - Fixed some typos in the POD. - Corrected the grammar to allow for a plan of 1..0 (infinite stream). - Started to add proper acknowledgements. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: post-YAPC::Europe CPANTS news
Michael Peters wrote: Adam Kennedy wrote: It might be an interesting idea to also add a dependencies_exist metric, that makes sure that all the dependencies that are declared actually exist in the CPAN. Dunno, could be of dubiously little value, but I just managed to somehow upload something with bad deps that I had installed on my local machine, but that weren't all on CPAN yet... I'm not sure this is such a good idea. There are several examples of modules that rely on other Perl modules that aren't on CPAN. For instance, svk relies on SVN::Mirror which is a part of svn. SWISH::HiLiter needs SWISH::API which is a part of swish-e. There are lots of perl modules tied to various projects that don't exist independently on CPAN. But frankly, if you are uploading modules to CPAN that can't possibly ever be installed with the CPAN client because you have to go install modules from somewhere else first, I'd consider that worth docking a kwalitee point over. 98%* of modules are going to pass this, 1% will fail and encourage more people to upload more things, and 1% will fail due to genuine errors we want to assist authors in catching. On another subject that came up today one one of my modules (specifically the new Test::Object dependency of PPI) it seems like it could be a bad idea to have explicit dependencies on the latest version of a dual-life module. One of the linux distro guys pinged me about Test::Object needing the very latest (CPAN-only) version of Test::Builder, because it means they can't package it properly for the distros without upgrading the main Perl package. Some packaging systems can't handle having the same file in more than one distro it seems. While this might seem like punishing people for depending on things that work, it's another red box to alert you to a possible problem, and the red box will dissapear on it's own when the next version of Perl comes out. I think it's worth considering. Adam K * Not actual percentages
Re: post-YAPC::Europe CPANTS news
Thomas Klausner wrote: Hi! On Thu, Sep 07, 2006 at 10:23:39AM +1000, Adam Kennedy wrote: - has_example I thought we were generally negative on this one, because it would encourage people to spuriously add trivial example directories to their distributions... Yes, but I've recently introduced the concept of 'optional' metrics. Optional metrics are not used to calculate an authors rank in the CPANTS game. Current optional metrics are 'is_prereq' and 'has_examples'. This also makes it possible to get 110% kwalitee at the moment :-) I saw that. The question is how many people are likely to be driven to add it just to get the green mark anyway (even if it doesn't alter the result of the game). Perhaps as an initial fix, we could make the visual distinction seem smaller? For example, instead of white box with squiggle, change it to a grey box with the same level of brightness as the green box? So the difference is reduced to a fairly subtle shade difference? As a secondary point, if we keep it you might also want to include /sample(s)/ and /demo(s)/. Thanks, added - declares_dependencies It might be an interesting idea to also add a dependencies_exist metric, that makes sure that all the dependencies that are declared actually exist in the CPAN. Dunno, could be of dubiously little value, but I just managed to somehow upload something with bad deps that I had installed on my local machine, but that weren't all on CPAN yet... It might also catch possible CPANTS bugs. Good point. I like it then :) - no_open_bugs If we are going to do this, we have to make sure that we DON'T include wishlist bugs in this metric, or it blows the validity all to hell. I was thinking of something like 'no open bugs with severity wishlist (or even unimportant) and more than two weeks old'. 'Taken' bug reports are obviously also not counted. Something along those lines seems good, the more sophisticated the better. The big question is, can you get data exported out of RT with enough resolution to do what you want? Adam K
Re: post-YAPC::Europe CPANTS news
Salve J Nilsen wrote: Thomas Klausner wrote: Oh, and if you want to join the fun and help a bit, here's a (probably incomplete) list of tasks: - Metrics: [snip] Would the metrics for community support channels that were suggested a while ago be welcome? (The discussion about them sort of died out :-\) I think the main issue with this was that it was really only a valid metric for huge modules, and for 90% of the smaller things there wasn't much point. For example, Config::Tiny or Catalyst::Plugin::Some::Random::Small::Plugin. And frankly, I don't think there's a good way to distinguish between should have a community and shouldn't need a community. On the other hand, what WOULD be interesting, is a check to make sure that the URIs of anything mentioned are still valid. So if the META.yml has a URI with a community page or what have you, that the page exists. The same sort of uris_exist could also check URIs in the main documentation. On the other hand, the downside with this is that modules could well have URIs that take actions in them, or aren't meant to be valid... maybe... Adam K
Re: post-YAPC::Europe CPANTS news
On 9/7/06, Salve J Nilsen [EMAIL PROTECTED] wrote: Thomas Klausner wrote: Oh, and if you want to join the fun and help a bit, here's a (probably incomplete) list of tasks: - Metrics: [snip] Would the metrics for community support channels that were suggested a while ago be welcome? (The discussion about them sort of died out :-\) For every uploaded module automatically forum is created on http://www.cpanforum.com/ I know not everyone likes this idea and some others have issues with the current form of CPAN::Forum (yes, I am working on some of these issues) but this basically means that every module *has* a community support channel. The question then might be if that channel is used. E.g. are there (recent) posts on the forum? How many posts are there? Have the questions been answered? Has the module author blessed the channel (or for that mater decided to point people to another support channel)? Oh, I would love a metric that is called has_posted_on_cpan_forum_that_author_is_monitoring_the forum even if it had a shorter name. Gabor
Re: post-YAPC::Europe CPANTS news
On Fri, Sep 08, 2006 at 09:15:47PM +1000, Adam Kennedy wrote: One of the linux distro guys pinged me about Test::Object needing the very latest (CPAN-only) version of Test::Builder, because it means they can't package it properly for the distros without upgrading the main Perl package. Some packaging systems can't handle having the same file in more than one distro it seems. Said maintainers can work round the deficiencies of their packaging systems by breaking out all the dual life modules from the core Perl package, and making them into other packages on which the core Perl package depends. In my opinion. Clearly this might be a bit tricky if the packager of Test::Object isn't the same person as the packager of core Perl, because then the former has to persuade the latter of the need for such a change. Alternatively said maintainers can work round the deficiencies of their packaging system by having another directory tree in @INC ahead of the core library paths, into which they install newer versions of dual life modules. This way no files need to be overwritten on disk, or dual-owned, yet Perl will still pick up the correct (newer) version. Nicholas Clark
Re: post-YAPC::Europe CPANTS news
On 9/8/06, Adam Kennedy [EMAIL PROTECTED] wrote: On another subject that came up today one one of my modules (specifically the new Test::Object dependency of PPI) it seems like it could be a bad idea to have explicit dependencies on the latest version of a dual-life module. One of the linux distro guys pinged me about Test::Object needing the very latest (CPAN-only) version of Test::Builder, because it means they can't package it properly for the distros without upgrading the main Perl package. Some packaging systems can't handle having the same file in more than one distro it seems. I think that this is a general problem that probably requires some pushback towards the packaging system maintainers. The concept that a package can contain numerous parts, some of which may be superseded by later released stand alone parts shouldnt be a surprise to anyone. It happens all the time in every aspect of life. This came up recently for me with regard to EU::MakeMaker and EU::Install. The package EU::Install is contained by both EUMM and EUI. In principle the EUMM package shouldnt install its EU::I unless the existing EU::I is older than the one it contains. OTOH, the EUI package should always be used if one wants to upgrade it alone. I personally dont think that this is a bizarre use case. EUMM needs to have EUI to do its thing, and EUMM needs to have EUI around to do its thing. But they can be updated independently. Such a chicken and egg kind of relationship probably isnt that unusual. The only solution can't be that you have to bundle them together or bundle them all independently. On win32 this is an old problem that is mostly dealt with transparently to the user (except when its done badly in which case things can go horribly wrong). Its common for a package to bundle various items, particularly .dll's, but not install them when it finds that later versions are available from some other source. BTW, im not saying that this is an easy problem to resolve, or that im interested in rushing out and solving it myself. But it seems to me to be one that needs solving. :-) I mean, we are talking about tools here, can you imagine going into a hardward store and finding out that you cant replace a tool from a toolset without replacing the entire toolset? Or conversly that nobody offers a complete toolbox just because then they would be forbidden from supplying the individual tools alone? Anyway, sorry, minor rant. Ill shut up now. :-) Cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: TAPx::Parser 0.20
On Thu, 2006-09-07 at 02:06 -0700, Ovid wrote: From running it against a few test suites and getting some strange results, it seems like TAPx::Parser doesn't like lines like ok 3 # comment It flags the corresponding result as being of type unknown. Unescaped hash marks are not allowed in test lines unless they begin a TODO or SKIP directive. Can you show the code which is producing this broken output? Is it something in Perl, maybe some hand-rolled stuff? Yeah, this is hand-rolled stuff. One example: http://search.cpan.org/src/TSCH/Glib-1.140/t/7.t As the comment in there says ... we do not use Test::More or even Test::Simple because we need to test order of execution... the ok() funcs from those modules assume you are doing all your tests in order, but our stuff will jump around. If this works, mind if I include it in the distribution? Nope, go ahead. -- Bye, -Torsten
Re: TAPx::Parser 0.20
On Wed, 2006-09-06 at 19:42 -0400, Michael G Schwern wrote: To accomplish what you want, use - ok 3 - comment OK, will do. Thanks for the explanation. -- Bye, -Torsten
Integrating Test::Run with Module::Build
Hi all!
Today, after a long session of hacking on XML-Grammar-ProductsSyndication
(more about that later), I experimented a bit with integrating Test::Run into
a Module::Build build system. It turns out to be very easy, with just having
to add ACTION_runtest and ACTION_distruntest with the appropriate logic. My
complete Build.PL (for the Test-Run distribution) now looks like this:
use strict;
use warnings;
use Module::Build;
my $class = Module::Build-subclass(
class = Test::Run::Module::Build,
code = 'EOF',
use strict;
use warnings;
sub ACTION_runtest
{
my ($self) = @_;
my $p = $self-{properties};
$self-depends_on('code');
local @INC = @INC;
# Make sure we test the module in blib/
unshift @INC, (File::Spec-catdir($p-{base_dir}, $self-blib, 'lib'),
File::Spec-catdir($p-{base_dir}, $self-blib, 'arch'));
$self-do_test_run_tests;
}
sub ACTION_distruntest {
my ($self) = @_;
$self-depends_on('distdir');
my $start_dir = $self-cwd;
my $dist_dir = $self-dist_dir;
chdir $dist_dir or die Cannot chdir to $dist_dir: $!;
# XXX could be different names for scripts
$self-run_perl_script('Build.PL') # XXX Should this be run
w/ --nouse-rcfile
or die Error executing 'Build.PL' in dist directory: $!;
$self-run_perl_script('Build')
or die Error executing 'Build' in dist directory: $!;
$self-run_perl_script('Build', [], ['runtest'])
or die Error executing 'Build test' in dist directory;
chdir $start_dir;
}
sub do_test_run_tests
{
my $self = shift;
require Test::Run::CmdLine::Iface;
my $test_run =
Test::Run::CmdLine::Iface-new(
'test_files' = [glob(t/*.t)],
# 'backend_params' = $self-_get_backend_params(),
);
return $test_run-run();
}
EOF
);
my $build = $class-new(
module_name = Test::Run,
requires =
{
'Class::Accessor' = 0,
'File::Spec' = 0.6,
'Test::Harness' = 2.53,
'Scalar::Util' = 0,
'TAPx::Parser' = 0.21,
},
dist_version_from = lib/Test/Run/Obj.pm,
);
$build-create_build_script;
Now, the -do_test_run_tests() method is much shorter than its Test::Harness
equivalent. I had to copy and paste some code in the $self-ACTION_...
methods. Perhaps the M::B hackers would like to abstract the common
functionality somehow.
In other news, Test::Run now makes use of TAPx::Parser to parse the TAP. It
still collects the statistics on its own, because I couldn't remember whether
TAPx::Parser does that or not, and it was too much work to do at one time.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
