How might we mark a test suite isn't parallalizable?
In HARNESS_OPTIONS we can set -jN to note we want parallel tests running, but how can a particular module, which might be buried in the dependency chain, tell the harness it can't do that? It seems to me that by the time the tests are running, it's too late because they are already in parallel and the best we can do is issue a warning or decide to fail.
Re: [QA2012] IRC Meeting 2011-01-12
In article 20120112232237.GA5030@swoosh, Philippe Bruhat (BooK) philippe.bru...@free.fr wrote: - as a side remark, it would be great if the companies that use perl would give back some of the money they saved by not having to pay for a Perl license especially for an event like this one, that is targetted at improving perl cpan What other language would they be using that required a license fee? That's not to say that they don't benefit from Perl being free, but at the same time, you're secretly saying that you wish Perl wasn't free, even if indirectly taxed. Let's not forget that many companies do give back by not giving money, but contributing to CPAN, sending patches, and many other things. Using open source is not without cost just because there is no license fee.
Re: Need suggestions for terminology
In article 20111205154758.gh17...@bytemark.barnyard.co.uk, David Cantrell da...@cantrell.org.uk wrote: There's at least one other significant difference: CPAN has an up-to-date index. BackPAN doesn't. Well, CPAN's index is also BackPAN's index. That is, neither of them include all of the files in the repository. I'd like to change that, but it also means abandoning the flat files in favor of something like SQLite.
Pod-Perldoc needs tests. You can help.
I've taken over Pod-Perldoc and was surprised to find that it has virtually no tests. When I started, it had several calls to pass() and a checked that three modules loaded. You can help change that. There are many interesting test challenges here. For instance, Pod::Perldoc::ToMan, perhaps the most used of all the formatters, shells out to pod2man and then to nroff. That's three things that need some encoding love. And, shelling out from a Perl program to a Perl program that is a call to a module makes it hard to test: the big red flag that Your Doing It Wrong. Many of the issues in RT deal with pagers and how they act on various systems. I have no idea how to test that. Maybe you do. There's a *::ToTk module. Good luck testing that. However, there are some things we can do to fail with better error messages. There are various niggling pod things that perldoc has to handle correctly, too, and I imagine testing those would benefit modules such as Pod::Checker. -- brian d foy brian.d@gmail.com
Re: RFC: Private CPAN In A Box
In article 02c001cc1a59$6865b810$39312830$@activestate.com, Jan Dubois j...@activestate.com wrote: AFAICT there is no good index for backpan though. There's a good index, but it lives on one of my private computers and is rather large. :)
Re: RFC: Private CPAN In A Box
In article BANLkTinzErQAnW4qthz=t1jdd8p3iou...@mail.gmail.com, David Golden xda...@gmail.com wrote: * You run the dependency analysis tool against your tarball, using the perl as a base and using the local+BackPAN to resolve dependencies. * Tool spits out the ordered list of tarballs (probably as URLs) needed to install the application I have this bit done but not public yet.
Re: Using CPAN or CPANPLUS to install a list of modules (even if already installed) into a specified location
In article 9c335568-ae99-4bce-9ad0-58e776e44...@matisse.net, Matisse Enzer mati...@matisse.net wrote: Is there an existing way to do the equivalent of: cpanp --prefix=/tmp/MyCollection --ignore-already-installed Module::One Module::Two ... I don't know how you would do it with cpanp. I do that with a force install, which always reinstalls. What happens when you run it as: cpan -f -i Module::One Module::Two cpan doesn't have a way to set the prefix on the command line, but you can load arbitrary config files: cpan -j config -f -i Module::One Module::Two
Re: Move Test::More development discussion back to perl-qa?
In article 4d4492ac.6080...@pobox.com, Michael G Schwern schw...@pobox.com wrote: Do people not care? Is it going over everyone's heads? Is everyone just waiting for it to be done? Does it not seem like TB2 is relevant? I want Test::Builder 2. I'm just full up with everything else I'm doing.
Re: Toolchain issues
In article k2i5d4beb41004290438sfd5fa38dj93c60571c10b...@mail.gmail.com, David Golden xda...@gmail.com wrote: Quick thoughts: 2. ExtUtils::MakeMaker and Module::Build - Serious!  HP-UX, and probably other OS's too, do not allow installation of  shared objects when the object already exists and is in use. That  means that all XS modules used by CPAN cannot be installed by CPAN. This is actually a problem with ExtUtils::Install, I think. The same problem exists on Windows, but EU::I uses a Win32 call to schedule the file for deletion on reboot before replacing it with a new one. That feature of ExtUtils::Installed caused many headaches for me on Windows and a lot of pain for some Windows admins. Apparently a normal user can bypass various lack of priveleges that would keep him from outirght deleting files using that trick. It corrupted many a Strawberry Perl installation which we were trying to keep pristine. I don't understand all the Windows stuff, but I know it really stumped some good admins for awhile because the user permissions looked like they should stop it.
Re: Toolchain issues
On Tue, May 4, 2010 at 6:07 PM, Jan Dubois j...@activestate.com wrote: That feature of ExtUtils::Installed caused many headaches for me on Windows and a lot of pain for some Windows admins. Apparently a normal Really? All it should take it putting an inheritable deny ACL for Delete Subfolders and Files on the install directory. I don't manage the Windows side. I was more annoyed that ExtUtils::Installed would try to delete a file, notice that it failed, then try to work around it's inability to delete the file. It failed correctly, but that wasn't good enough, I guess. :) -- brian d foy brian.d@gmail.com http://www.pair.com/~comdog/
Re: Post-Hackathon plans?
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article 4b8c3be2.7010...@pobox.com, Michael G Schwern schw...@pobox.com wrote: I'm planning out my hackathon trip, and I figure it would be silly to fly all the way to Vienna, hack, and then fly all the way back home without at least spending a day or two bumming around. I've got at least one day free after the hack-a-thon and no plans for it. Popping over to Bratislava sounding interesting.
Re: The Test Feature I Want
In article 200812121032.00515.enoba...@gmail.com, Eric Wilhelm enoba...@gmail.com wrote: # from Ovid # on Friday 12 December 2008 04:37: Running a single test means that I ... want to run that test. ... Here are conditions I see crop up in tests:  POD_COVERAGE ... FAST_TESTS ... PROFILE_TESTS ... doesn't (and usually shouldn't) know if other tests are being run ... ... prove shouldn't have special-case knowledge ... ... but I don't know if anyone else would benefit or if this is the right approach. This is exactly the sort of thing I was getting at when we had the discussion about the xt/ directory. This is also what I was thinking when I made Test::Manifest. I wanted something external to the build file where I could change the sets of tests to run. It has rudimentary support for test levels, but I haven't connected it to anything higher than that.
Has anyone integrated Perl module testing and TeamCity?
Is anyone doing continuous testing of Perl modules with TeamCity? I've just started a project using that, and while it looks straightforward, I don't want to reinvent anything that anyone else has done. Specifically has anyone: * made stuff to turn TAP into TeamCity messages? * tracked Devel::Cover trends and stored them in TeamCity? * tracked NYTProf results and stored them in TeamCity?
Re: Sum of all tests for a module/application
In article [EMAIL PROTECTED], nadim khemir [EMAIL PROTECTED] wrote: Hi, I was discussing one of my modules with a friend and he asked how many tests I had. I answered 500 hundred but it then hit me that to have the module working I had to rely on other modules written by other people. I've thought about this too, but a test in a Perl file isn't really the test that most people would find interesting. For instance, here's a common sequence in my tests. I have four lines of ok N, but it's really just one functional test: use_ok( $class ); can_ok( $class, $method ); ok( -e $input_file, Input file exists ); is( $class-$method( $input_file ), $expected, Got it right! ); I'm not saying we shouldn't figure out the grand number of tests, but that we should temper that knowledge with reality. :)
Re: Announce: Test::Formats 0.11
In article [EMAIL PROTECTED], Randy J. Ray [EMAIL PROTECTED] wrote: I settled on the name Test::Formats. At present, the module provides Test::Formats and Test::Formats::XML. The latter has all the testing-hooks for checking XML documents against DTDs, XML Schema descriptions and RelaxNG schemas. What is Test::Formats supposed to do? I know you described the XML use case, but that doesn't seem like you're testing a format, or that format is too broad a term. Maybe it's really Test::StructuredText? Maybe not; would this handle thigns like checking the structure of a binary data file? I guess it gets down to semantics, but it sounds odd to me to call XML or YAML a format. Your examples sound like you are validating against a schema, which often doesn't care about the format (e.g. whitespace, etc). Is there a way to hide more of the magic though? Why import anything (especially with a non-standard import list)? Perhaps you can auto-detect the source type and dispatch it with hidden magic or with an optional schema. How about calls like: schema_validates_ok( $source, [$schema] ); schema_validates_ok( $source, xml = $schema ); schema_validates_ok( $source, yaml = 1.0 ); schema_validates_ok( $source, 'quoted-csv' ); That way, it really is an umbrella class rather than just a module loader. Despite the name, it sounds like a cool module if it does what I think it does. :)
Re: How to write a test for Test::Builder?
In article [EMAIL PROTECTED], Nicholas Clark
[EMAIL PROTECTED] wrote:
But it seems that this bug is only fixed as a side effect of that change, and
it's not actually tested for. What's the best way to write a test that fits
within the current frameworks to prevent any regression?
It's not obvious to me how to make use_ok() test for failure.
Are you looking for Test::Builder::Tester?
#!perl
use Test::More tests=1;
use Test::Builder::Tester;
test_out('not ok 1 - use Fcntl;');
test_fail(+1);
use_ok 'Fcntl', 'Pie';
test_test( Fails for bad export);
__END__
Re: CPAN Testers - Author Notification System
In article [EMAIL PROTECTED], David Golden [EMAIL PROTECTED] wrote: On Thu, Sep 11, 2008 at 5:17 PM, Michael G Schwern [EMAIL PROTECTED] wrote: The way it looks right now, I want my CC's back. :( Well, I guess we win some and we lose some. Just brainstorming for the moment, but if we had an option to forward all your FAIL or UNKNOWN reports to the distribution's RT queue Ouch. Some people might want that, but only as an opt-in thing please. I have the same view as Schwern: getting individual email reports for every fail meant that they could live in my email. When they live in my email, I clean them out as I fix them. If it is in my email folder, it's an open issue. If it's not, it's not. :) Today I considering writing a bot to listen to cpan-testers and simply resend individual reports to me, depending on how quickly the opt-in stuff gets set up and if it actually works.
Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)
In article [EMAIL PROTECTED], Dave Rolsky [EMAIL PROTECTED] wrote: ThatÄôs CPANTS, the useful part of it anywayĶ except that the feedback cycle is even *much* slower there than with the Testers. Is not! Check out Test::Kwalitee on cpan. I've taken to adding that to my maintainer-only tests for my distros. And you can run cpants_lint.pl yourself too. Module::Release now has that built in as well.
Re: passing the baton onwards
In article [EMAIL PROTECTED], (Andreas J. Koenig) [EMAIL PROTECTED] wrote: On Fri, 05 Sep 2008 17:15:04 -0700, brian d foy [EMAIL PROTECTED] said: In article [EMAIL PROTECTED], (Andreas J. Koenig) [EMAIL PROTECTED] wrote: On Fri, 05 Sep 2008 10:54:40 -0700, brian d foy [EMAIL PROTECTED] said: Or, Andreas could change PAUSE, which is a bit more involved :) Do you not know the abandoned flag? Or not considering it appropriate? *I* know about it, but you also have to register the module, don't you? Yes, but this is probably a good thing. I'm thinking that someone who doesn't want to maintain the module probably won't do the extra work to register it then set the flag. I'm not thinking about what people should do, just what they won't do. I'll look at making that list of abandoned modules, and for now I'll go through the list I have and set their flags, etc.
Re: What do you want? (was Re: The relation between CPAN Testers and quality)
In article [EMAIL PROTECTED], David Golden [EMAIL PROTECTED] wrote: On Fri, Sep 5, 2008 at 12:42 AM, Andy Lester [EMAIL PROTECTED] wrote: I want nothing in my inbox that I have not explicitly requested. I want to choose how I get reports, if at all, and at what frequency. I'm going to take the first steps towards this over the weekend by deprecating author CC's in the code and encouraging top testers to upgrade their tools. I remember some discussion about setting some thing to opt-in or -out of those. I'd hate to lose those in my email because other people don't want to filter their mail.
Re: What do you want? (was Re: The relation between CPAN Testers and quality)
In article [EMAIL PROTECTED], Andy Lester [EMAIL PROTECTED] wrote: I'd hate to lose those in my email because other people don't want to filter their mail. I'd hate to get spammed because other people don't want to sign up to receive them. You keep saying spam, but that's not the right term. You're being an ass characterizing it like that. Right now there is not a way to opt in, but there is a way to ignore it if you don't want to see it. I'll sign up for it when there is a way to do it. It's not a matter of me not wanting to do something, but jsut dealing effectively with the current situation. So, Andy, put up or shut up. Send in the patches.
Re: passing the baton onwards (was Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it))
In article [EMAIL PROTECTED], Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Sep 04, 2008 at 02:19:26PM -0400, Greg Sabino Mullane wrote: I recognize that CPAN is a volunteer effort, but it does seem to me there is a implicit responsibility on the part of the author to maintain the module going forward, or to pass the baton to someone else. Call it a Best Is there an easy central visible way to flag up a module as up for adoption? What should have been the right list to ask that question on? A couple of the PAUSE admins have been talking about that, but we haven't really decided anything about how it should happen. There would probably be some virtual PAUSE ID that people could pass primary maintainership too and once those modules are there, someone could request maintainership of them without a waiting period. That's the way that would work with what is already in place, although someone has to upload a new dist for it to show up in the new account. I was thinking we'd want to do that anyway to at least modify the docs to note its status. Or, Andreas could change PAUSE, which is a bit more involved :)
Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)
In article [EMAIL PROTECTED], chromatic [EMAIL PROTECTED] wrote: If I could see somehow that my distribution implicitly runs on Perl 5.001 (or explicitly runs only on 5.11.0), or that it has no Makefile.PL or Build.PL, or any of the other dozens of packaging quirks that can cause problems, I could fix them before uploading and before triggering a wave of testing. That's what Module::Release does, and since the QA Hackathon in Oslo, it even tests under multiple perls. It can check kwalitee (or not), or anything else that you like.
Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)
On Fri, Sep 5, 2008 at 6:17 PM, chromatic [EMAIL PROTECTED] wrote: On Friday 05 September 2008 16:52:05 brian d foy wrote: In article [EMAIL PROTECTED], chromatic If I could see somehow that my distribution implicitly runs on Perl 5.001 (or explicitly runs only on 5.11.0), or that it has no Makefile.PL or Build.PL, or any of the other dozens of packaging quirks that can cause problems, I could fix them before uploading and before triggering a wave of testing. That's what Module::Release does, and since the QA Hackathon in Oslo, it even tests under multiple perls. It can check kwalitee (or not), or anything else that you like. Hm. What's your thought on turning that into something which a Module::Build or ExtUtils::MakeMaker plugin could run on ./Build distcheck or make distcheck? Module::Release already does that, too. You don't run it from make, you just type 'release' at the command line and it checks the `make test` and `make disttest`. There is a Module::Build plugin, but I haven't verified that it works for my latest versions yet (it probably doesn't). If someone wants to integrate it some other way, they can, but I have a different workflow that works a lot better for me. Module::Release tests a bunch of things, and if anything fails, it stops and doesn't release anything. The major bits are the distro tests, prereqs (I'm moving Test::Prereq out of my dists and into Module::Release), kwalitee, and source control status. Although you can look at the 'release' script in search.cpan.org, here's the output of a dry run to show you how it works (even more stuff happens for a real release after all this stuff passes)l: macbookpro_brian[686]$ release -t Testing with /usr/local/bin/perl5.10.0 Cleaning directory... no Makefile---skipping Recreating make file... done Running make... done Checking make test... all tests pass Checking prereqs... done Making dist... done Checking make disttest... all tests pass Testing with /usr/local/bin/perl Cleaning directory... done Recreating make file... done Running make... done Checking make test... all tests pass Checking prereqs... done Making dist... done Checking make disttest... all tests pass Testing for kwalitee Cleaning directory... done Recreating make file... done Running make... done Making dist... done Checking kwalitee... done Checking source repository Checking state of Git... Git up-to-date on branch 1 Cleaning directory... done -- brian d foy [EMAIL PROTECTED] http://www.pair.com/~comdog/
Re: About tidying up Kwalitee metrics
In article [EMAIL PROTECTED], Thomas Klausner [EMAIL PROTECTED] wrote: The goal of deducting a kwalitee point for 'no_cpants_errors' is to get authors to report CPANTS bugs. Why do you need authors to report those? After a run, you have a list of all of the errors already.
Re: Proposed (optional) kwalitee metric; use re 'taint'
In article [EMAIL PROTECTED], Paul Fenwick [EMAIL PROTECTED] wrote: * Does anyone think this is a bad idea? I think it's an exceedingly bad idea. The more things I have to pay attention to in CPANTS, the less likely that I'm going to do anything about it. You might like using it, but I'm not going to need it in almost any of my code, and I would have to ignore this metric. CPANTS gaming made my distributions better, but only because there were a limited number of things I had to fix or change. For a long time, I was the guy on the top of the list. I've been ignoring CPANTS for several months because of the explosion of metrics, although I was convinced last week to look again. If I start ignoring metrics, I'll just start ignoring CPANTS again. * Is there someplace this should be going besides from CPANTS? It's definitely a common mistake that module authors can easily fix. I don't know about common. I don't even think taint checking is common, even if it should be.
Re: Proposed (optional) kwalitee metric; use re 'taint'
In article [EMAIL PROTECTED], Paul Fenwick [EMAIL PROTECTED] wrote: I'm very much not happy to get bug reports and test failures and big red bars against my distributions because an automated heuristic which applies only to some cases decided that it knows better about how to write code than I do. One could argue this is the case for all the CPANTS tests. Why should your code use strict, or warnings, or Test::Pod::Coverage, or have its tests in t/ ? These are all just automated heuristics telling me how to write my code. Yes, those metrics are telling you how to write your code and I wish they weren't part of CPANTS either.
Re: Proposed (optional) kwalitee metric; use re 'taint' / Per-author tests?
In article [EMAIL PROTECTED], Paul Fenwick [EMAIL PROTECTED] wrote: On that note, surely we could save a lot of anguish with regards to many of the CPAN tests just by making the optional ones[1] actually optional? As a completely off-the-bat suggestion that could be controlled by META.yml: Why should I have to work to disable something I don't want and doesn't apply to me? Why make me do something that distracts me from the real issue of writing better modules and packaging distributions wisely?
Re: New CPANTS metrics
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: testing for warnings during tests
In article [EMAIL PROTECTED], Gabor Szabo [EMAIL PROTECTED] wrote: Having those warnings during tests is a problem that should be somehow solved. I'd like to have a cpan-testers report whenever my test suite issues warnings. It's not a new category. If the tests all pass it's still a PASS. Someone was talking about developer preferences before. I'd set a send report on warning feature. Not that I care that much to do anything about it right now :)
Video of Oslo QA Hackathon closing remarks
I've managed to edit the video from the closing remarks at the Oslo QA Hackathon. http://vimeo.com/1043143 It's nothing fancy, but it's the first video I've made and next time it will be better :)
Re: Oslo Hackathon schedule page
In article [EMAIL PROTECTED], Thomas Klausner [EMAIL PROTECTED] wrote: Hi! On Mon, Mar 31, 2008 at 10:58:39AM -0400, David Golden wrote: For those attending the Oslo hackathon, please see the new schedule page: Are there any plans on short talks introducing people to the various topics? I could prepare a short intro to CPANTS, and list my 'Testing Best Practices' questions (which are also CPANTS related..) Salve mentioned at the Oslo.pm meeting tonight that he wants to start Saturday morning with people giving three minute talks on what they plan to work on. That would be the informal sort of talk where you just stand up and talk, not the sort informal-but-I-slides lightning talk stuff. In particular, he mentioned: * Who you are * What you are working on * Why it's important
Re: expanding the cpan script, and Module
In article [EMAIL PROTECTED], David Golden [EMAIL PROTECTED] wrote: It sounds like what you really want is a new config option. The cpan script is just a pass-through to CPAN::Shell. That's not really true. Although I use CPAN::Shell for some things, cpan isn't just passing things along. My program is a different interface using the same backend. I suggest posting your request to the CPAN.pm RT queue -- Andreas (and others like me) monitor it and it keeps the backlog of bugs and feature requests in one place. If he's talking about my script, that's the cpan-script queue :)
Re: ignoring already installed modules during a cpan install
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Andrew Hampe [EMAIL PROTECTED] wrote: is there an existing, or planned setting, for the CPAN utilities, that will cause it to ignore any already installed dependencies, during an installation, except for modules installed during the current session. For example: cpan install Foo Don't use that install there. It's either the -i switch or just a list of modules. cpan Foo if this feature does not exist, would a patch providing this be welcome? I'd gladly look at the patch, but I don't see how that feature would work. If you have a solution, let me know through the cpan-script RT queue. Thanks. :)
Re: Ignoring parts of compiled-in @INC during CPAN builds
In article [EMAIL PROTECTED], Matisse
Enzer [EMAIL PROTECTED] wrote:
On Nov 23, 2007, at 8:19 AM, brian d foy wrote:
If this were my problem, I think my first attempt would be writing my
own CPAN.pm script that set the environment and config just the way I
wanted it.
If you mean writing a script that uses CPAN.pm then that is what I
have done. Something like this:
use CPAN;
my $settings = _get_settings();
CPAN::HandleConfig-load();
$CPAN::Config-{'makepl_arg'} = $settings-{'makepl_arg'};
$CPAN::Config-{'build_dir'}= $settings-{'build_dir'};
# Etc.
# then later
Where in there are you modifying @INC? How is this script not working
for you?
Re: Ignoring parts of compiled-in @INC during CPAN builds
In article [EMAIL PROTECTED], Matisse Enzer [EMAIL PROTECTED] wrote: What I want is to EXCLUDE certain directories from @INC during the build process, specifically anything under /Library/Perl, especially in the sub-processes that CPAN::Shell creates when building each distribution. The desired result is that build dependencies will not be satisfied by any previously installed modules in the excluded directories. If this were my problem, I think my first attempt would be writing my own CPAN.pm script that set the environment and config just the way I wanted it. I've done this sort of thing already to put custom minicpans on CD, etc. You don't have to disturb any other settings in CPAN.pm because it's a per-session config that disappears at the end of the run. Once you set up the environment, you start up the CPAN shell programmatically and procede as normal.
Re: Dropping 5.5 support from my modules.
In article [EMAIL PROTECTED], Michael G Schwern [EMAIL PROTECTED] wrote: This is an announcement that my modules will no longer try to be backwards compatible with 5.5.x. Fair enough. Can you make a list of the last versions of all of those that should work with Perl5.005? I suppose that's the current list right now.
Re: Dropping 5.5 support from my modules.
In article [EMAIL PROTECTED], Michael G Schwern [EMAIL PROTECTED] wrote: brian d foy wrote: Fair enough. Can you make a list of the last versions of all of those that should work with Perl5.005? I suppose that's the current list right now. Pretty much. If anyone wants to put in the effort to make such a list they can, knock yourself out. No effort: /MINICPAN/authors/id/M/MS/MSCHWERN/Alien-SVN-1.4.5.2.tar.gz Alien::SVN = 1.4.5.2 /MINICPAN/authors/id/M/MS/MSCHWERN/AnyLoader-0.04.tar.gz AnyLoader = 0.04 /MINICPAN/authors/id/M/MS/MSCHWERN/Bone-Easy-0.04.tar.gz Bone::Easy = 0.04 Bone::Easy::Rules = /MINICPAN/authors/id/M/MS/MSCHWERN/Bundle-Schwern-0.01.tar.gz Bundle::Schwern = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/CLASS-1.00.tar.gz CLASS = 1.00 /MINICPAN/authors/id/M/MS/MSCHWERN/Carp-Assert-0.20.tar.gz Carp::Assert = 0.20 /MINICPAN/authors/id/M/MS/MSCHWERN/Class-Fields-0.203.tar.gz Class::Fields = 0.203 Class::Fields::Fuxor = 0.06 public = 0.04 protected = 0.04 private = 0.04 Class::Fields::Inherit = 0.06 Class::Fields::Attribs = 0.03 /MINICPAN/authors/id/M/MS/MSCHWERN/Class-Object-0.01.tar.gz Class::Object = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/Class-Virtual-0.06.tar.gz Class::Virtually::Abstract = 0.03 Class::Virtual = 0.06 /MINICPAN/authors/id/M/MS/MSCHWERN/Class-WhiteHole-0.04.tar.gz Class::WhiteHole = 0.04 /MINICPAN/authors/id/M/MS/MSCHWERN/D-oh-Year-0.06.tar.gz y2k = 0.1 D::oh::Year = 0.06 /MINICPAN/authors/id/M/MS/MSCHWERN/DNA-0.03.tar.gz DNA = 0.03 /MINICPAN/authors/id/M/MS/MSCHWERN/Devel-Tinderbox-Reporter-0.10.tar.gz Devel::Tinderbox::Reporter = 0.10 /MINICPAN/authors/id/M/MS/MSCHWERN/Dunce-0.03.tar.gz Dunce::Files = 0.03 /MINICPAN/authors/id/M/MS/MSCHWERN/Exporter-Lite-0.02.tar.gz Exporter::Lite = 0.02 /MINICPAN/authors/id/M/MS/MSCHWERN/ExtUtils-Install-1.44.tar.gz ExtUtils::Packlist = 1.43 ExtUtils::Installed = 1.43 ExtUtils::Install = 1.44 /MINICPAN/authors/id/M/MS/MSCHWERN/ExtUtils-MakeMaker-6.36.tar.gz ExtUtils::MM_VMS = 5.76 ExtUtils::MY = 0.03 ExtUtils::MM_MacOS = 1.1 ExtUtils::MM_Cygwin = 1.1 ExtUtils::MM_DOS = 0.04 ExtUtils::MM = 0.07 ExtUtils::MM_OS2 = 1.07 ExtUtils::Liblist::Kid = 1.33 ExtUtils::MM_UWIN = 0.04 ExtUtils::Mksymlists = 1.21 ExtUtils::MM_NW5 = 2.1 ExtUtils::MakeMaker::vmsish = 0.03 ExtUtils::MakeMaker::Config = 0.04 ExtUtils::MM_Win95 = 0.06 ExtUtils::MM_QNX = 0.04 ExtUtils::MM_Unix = 1.54 ExtUtils::MakeMaker = 6.36 ExtUtils::MM_VOS = 0.04 ExtUtils::MM_Win32 = 1.15 ExtUtils::testlib = 1.17 ExtUtils::MM_AIX = 0.05 ExtUtils::Liblist = 1.03 ExtUtils::Command::MM = 0.07 ExtUtils::MM_BeOS = 1.07 ExtUtils::MakeMaker::bytes = 0.03 ExtUtils::Mkbootstrap = 1.17 ExtUtils::MM_Any = 0.15 /MINICPAN/authors/id/M/MS/MSCHWERN/Function-Override-0.02.tar.gz Function::Override = 0.02 /MINICPAN/authors/id/M/MS/MSCHWERN/Geo-Walkabout-0.01.tar.gz Geo::Walkabout::Class::DBI = Geo::Walkabout::Line = 0.01 Geo::Walkabout::Utils = Geo::Walkabout::Chain = 0.02 Geo::Walkabout = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/Gravatar-URL-0.01.tar.gz Gravatar::URL = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/Sex-0.69.tar.gz Sex = 0.69 /MINICPAN/authors/id/M/MS/MSCHWERN/Test-AtRuntime-0.02.tar.gz Test::AtRuntime = 0.02 /MINICPAN/authors/id/M/MS/MSCHWERN/Test-Harness-Straps-0.29.tar.gz Test::Harness::Iterator = 0.02 Test::Harness::Assert = 0.02 Test::Harness::Straps = 0.29 Test::Harness::Results = 0.01 Test::Harness::Point = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/Test-Legacy-1.2502.tar.gz Test::Legacy::More = Test::Legacy = 1.2502 /MINICPAN/authors/id/M/MS/MSCHWERN/Test-Simple-0.72.tar.gz Test::More = 0.72 Test::Builder = 0.72 Test::Simple = 0.72 Test::Builder::Tester::Color = Test::Builder::Tester = 1.09 Test::Builder::Module = 0.72 /MINICPAN/authors/id/M/MS/MSCHWERN/Text-Metaphone-2.00.tar.gz Text::Metaphone = 2.00 /MINICPAN/authors/id/M/MS/MSCHWERN/Tie-Cache-LRU-0.21.tar.gz Tie::Cache::LRU::Array = 0.02 Tie::Cache::LRU::Virtual = 0.01 Tie::Cache::LRU::LinkedList = 0.01 Tie::Cache::LRU = 0.21 /MINICPAN/authors/id/M/MS/MSCHWERN/Tie-Math-0.10.tar.gz Tie::Math = 0.10 /MINICPAN/authors/id/M/MS/MSCHWERN/Tie-VecArray-0.01.tar.gz Tie::VecArray = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/UNIVERSAL-exports-0.05.tar.gz UNIVERSAL::exports = 0.05 /MINICPAN/authors/id/M/MS/MSCHWERN/UNIVERSAL-require-0.11.tar.gz UNIVERSAL::require = 0.11 /MINICPAN/authors/id/M/MS/MSCHWERN/XPlanner-0.01.tar.gz XPlanner::Iteration = XPlanner::Story = XPlanner::Project = XPlanner::Object = XPlanner::Person = XPlanner = 0.01 /MINICPAN/authors/id/M/MS/MSCHWERN/foundation-0.03.tar.gz foundation = 0.03 /MINICPAN/authors/id/M
Re: New proposed CPANTS metric: prereq_matches_use
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
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: Mad TAP proposal
In article [EMAIL PROTECTED], Andy Armstrong [EMAIL PROTECTED] wrote: We have this ticket in the Test::Harness RT queue: http://rt.cpan.org/Ticket/Display.html?id=29633 Martin Thurn is asking for a SKIP_OUT directive that would skip all remaining test files and return a PASS. Well, if we have the Test Steering Protocol, wouldn't the best thing be to group the tests-to-skip in an exclude directive? TSP version 1 include non-gui exclude gui I hadn't been paying too close attention, but it looks like TSP might be able to do the stuff I am doing with Test::Manifest. If TSP become core, that would be really nice. :)
Re: [tap-l] Mad TAP proposal
In article [EMAIL PROTECTED], Eric Wilhelm [EMAIL PROTECTED] wrote: # from Andy Armstrong # on Wednesday 31 October 2007 16:51: But what about a more general mechanism? A TAP directive that means 'schedule these other tests'. So then you'd have a controller test which was the only one directly visible to Test::Harness and that'd decide which other tests to run. It sounds like it would be re-creating a lot of the same functionality needed for declarative extra testing and/or Test::Manifest. I don't care if Test::Manifest gets folded into the new stuff, even if re-implemented. If I can do the same thing with the core test modules I don't need Test::Manifest anymore. :) Test::Manifest can do this though. I list tests in t/test_manifest, which doesn't have to exist until `make test` time. In t/test_manifest, there is an ;include directive to include other files that have other lists of tests, recursively. There's also a way to mark test levels, so I can run all tests at level 1, or level 2, or whatever without worrying about which diretories or names there are. All that stuff is unconnected to the structure of t/.
Re: [tap-l] Mad TAP proposal
In article [EMAIL PROTECTED], Andy
Armstrong [EMAIL PROTECTED] wrote:
On 1 Nov 2007, at 14:12, Michael Peters wrote:
Yeah, but from the user's PoV this is pretty easy:
# t/controller.t
use Test::Steering;
include ('xt/frob') if frob_avail();
include ('xt/slow') if all_the_time_in_the_world();
That would happen at `make test` time (or whatever M::B does)? When I
want this sort of thing with Test::Manifest, I create t/test_manifest
at
`make time`.
It might be interesting to reflect on the harness though, and write to
the test queue. I don't think I need this. I just wanted to say
reflect :)
use Test::Harness;
add_test_file( 'foo.t', AT_END ); # or NEXT, or whatever
Re: a scheme for extra testing
In article [EMAIL PROTECTED], Eric Wilhelm [EMAIL PROTECTED] wrote: aside( You wouldn't have to say anything about tests that don't need anything special, just tests that are special. Why would non-special tests be in xt/? I mean special as in different from everything else in the same directory, so, perhaps different in the requirements from the other tests in that directory. I don't have a situation in mind though. It just seemed like the next place to take the idea. :)
Re: a scheme for extra testing
In article [EMAIL PROTECTED], Eric Wilhelm [EMAIL PROTECTED] wrote: Hi all, I've been organizing my thoughts about this and have gotten this far: http://scratchcomputing.com/tmp/extra_testing.txt The profile at the end of that looks interesting, and I immediately thought about a way in your format to declare prereqs per test (rather than just per directory). You wouldn't have to say anything about tests that don't need anything special, just tests that are special.
Re: Test::Harness::Straps is going away
In article [EMAIL PROTECTED], Ovid [EMAIL PROTECTED] wrote: Hi all, I'm sure that many of you are aware of this, but I wanted to remind you that with the upcoming release of Test::Harness 3.0, Test::Harness::Straps is going away. Do you mean that Test::Harness 3.0 won't have it but it will still be there in earlier releases, or that you're going to remove any trace of it from CPAN so it looks like it never existed?
Re: Searching CPAN repositories in a chain
In article [EMAIL PROTECTED], Matisse Enzer [EMAIL PROTECTED] wrote: CPAN::Mini is designed to mirror a public CPAN, not to be part of a search path, which is what I want. that's what urllist in the CPAN.pm config is for.
Re: Test::Pod / YAML explodes (and taking cpants with it...)
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.
Prior art for testing against many local perls?
Without getting into a bikeshed discussion, I'm looking for prior art to test a tarball against a list of local perls before I write my own thing. This sounds like a fun and mostly easy project, but I don't want to reinvent the wheel. I want to take a distro tarball and test it against every perl I have installed. This is development testing, not end user / installation testing: % test_with_every_perl foo-1.1.tgz Testing with perl5.6.2. Testing with perl5.8.0. Testing with perl5.9.5. At the end I get a nice report saying what went wrong with each version. This is something that I want to run right in my sandbox. The process is really easy: unpack the distro, use the appropriate perl with Makefile.Pl, and capture the results to make the report. So, who's already done this? :) -- brian d foy, [EMAIL PROTECTED] Subscribe to The Perl Review: http://www.theperlreview.com
Re: add points for registered namespaces
In article [EMAIL PROTECTED], demerphq [EMAIL PROTECTED] wrote: On 8/21/07, brian d foy [EMAIL PROTECTED] wrote: The effect of this kwalitee metric would be that fewer modules are registered as I or Adam just stop paying attention because it's too much work now. Maybe you need more assistants to help out? We don't really need more assistants. People are added as PAUSE admins from time to time on the recommedation of the current PAUSE admins. Anyone interested in helping can start by reading the [EMAIL PROTECTED] list for a while to see how things work, then slowly starting to participate, and eventually gaining the trust of everyone before finally being trusted with PAUSE powers. Personally i always found the module registration process to be more opaque than it should be, and IMO opening it up a bit might be a good call. What's opaque about it? I'm happy to answer any questions, but it's really not that complicated or secretive. *Everything* happens in public on the [EMAIL PROTECTED] list.
Re: add points for registered namespaces
In article [EMAIL PROTECTED], Cyberiade . it Anonymous Remailer [EMAIL PROTECTED] wrote: there's a lot of questionable modules being uploaded to CPAN which create top-level namespaces, very often not even being self-explanatory. it would be nice to add points for modules which have registered namespaces. this should encourage more appropriate module naming. Please don't do that. It has nothing to do with quality in any sense, and it would create a lot more work for us PAUSE admins. There are three of us who handle the registrations now although it's mostly me. I don't want to have to see tens of messages every day which I have to respond to and suggest more meaningful names. The effect of this kwalitee metric would be that fewer modules are registered as I or Adam just stop paying attention because it's too much work now.
Re: add points for registered namespaces
In article [EMAIL PROTECTED], Michael G Schwern [EMAIL PROTECTED] wrote: WRT the intent of forcing the user to get approval for their module: while it's nice to ask for opinions for your module, it sucks to hold up sharing your new module with the world while waiting for humans to respond. And [EMAIL PROTECTED] can be really, really slow. It can be slow, but generally I clear out the queue daily. The CPAN faq says that you don't have to wait to upload your module though. You can always change the name later.
Re: a standard place for extra tests
In article [EMAIL PROTECTED], Adriano Ferreira [EMAIL PROTECTED] wrote: On 8/17/07, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Adriano Ferreira [EMAIL PROTECTED] wrote: ...smells a lot like Test::Manifest, which is just test. In t/test_manifest, you just list the files that you want. Optionally, you can set a test level and mark some tests only happening at certain levels. The only drawback is redundant information: there are the tests and the list of tests. Keeping tests in t/ with some fine way to discover what they are good for (according to Chris' idea) may be promising if not too magical. I've yet to provide the make testmanifest homolog to make manifest because so far I just `find . -name *.t test_manifest. There is a bit more work to maintain that, but it's a small bit of work to the current alternatives, especially when I want to repeatedly run a subset of tests by replacing test_manifest temporarily. Even if people don't like Test::Manifest, the solution is probably the same for any other suggestions: override parts of Test::Harness to discover the file names you want to test, or override runtests. Those are both very short routines that hand off things to the heavy lifters.
Re: a standard place for extra tests
In article [EMAIL PROTECTED], Adriano Ferreira [EMAIL PROTECTED] wrote: Testing some Author stuff would be rarer than having author tests. So maybe we could standardize on something like t/author and when other value is desirable, a key/value pair may be specified in META.yml (and in Makefile.PL/Build.PL). ...smells a lot like Test::Manifest, which is just test. In t/test_manifest, you just list the files that you want. Optionally, you can set a test level and mark some tests only happening at certain levels. In some cases, I even auto-generate the t/test_manifest so it only has the files that I want to test in that situation. Other than t/test_manifest, I don't worry about magical names or changing all the tools for yet more special cases.
Re: Which Modules Does Your Distro Need?
In article [EMAIL PROTECTED], Ovid [EMAIL PROTECTED] wrote: Imagine this: ./Build testdeps That would be a custom action which would load a special Test::More wrapper which, at the end of each test program, cache %INC. I named mine Test::Prereq. :)
Re: .t files as specs
In article [EMAIL PROTECTED], Andy Lester [EMAIL PROTECTED] wrote: On Jun 19, 2007, at 10:52 AM, Mike Malony wrote: So I'm working my project, and I've got one other more junior coder with me. Has anyone tried writing test files as part of their spec's? An overview document would also be needed, and some time walking through the expected testing. But it sure would be setting clear expectations. I highly recommend writing your API POD, then the tests, For these things, I tend to write the tests first, because that shows me what I want the API to be. The tests don't have to be the final product, but writing example code brings out all the things you didn't think of when you dreamt up the API.
Re: CPANTS: suggestion for a new metric
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)
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: Testing URIs in POD
In article [EMAIL PROTECTED], Ian Malpass [EMAIL PROTECTED] wrote: I've started crafting Test::Pod::URI to extract URIs from POD and check them to make sure they work. However, my CPAN-fu has been weak today, so I thought I'd mail here and see if anyone knew of anything out there that already does such a thing. Anyone? I have something that does that for the perlfaq (I think the details of the source repo are in perlfaq.pod), but it's very low tech. It's not a module, either. It's just a script. I'd like to see a base module for this task, maybe Pod::Extract::URI. Test::Pod::URI could then use that. It would also be nice to have something to parse URI in the prose as well as the code, even if it's not tagged as a URI. Maybe there isn't a perfect solution to that, but even a 90% one would be nice. :) I'm looking forward to whatever you come up with :)
Re: CPANTS: suggestion for a new metric
[[ 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: suggestion for a new metric
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: Eliminating STDERR without any disruption.
In article [EMAIL PROTECTED], Michael G Schwern [EMAIL PROTECTED] wrote: A. Pagaltzis wrote: The most bangs I can count instantly by looking at them is four. For five bangs and up, all I see is âlots of bangs.â I have to count character by character to tell them apart. Visually, I canât distinguish `fatal` from `fail` at all. Another problem is that Iâd never remember the exact hierarchy. So with your proposal Iâd have to count bangs for any message of import, and then go look which number means what. Do you, as a human, have to exactly distinguish them? Isn't the content of the message and the rough number of bangs enough? not ok 1 ! Failed test in foo.t line 2 ok 2 !!! WHOA! The fabric of the universe just broke down! !!! This should never happen! Please contact the author immediately! if you're going to use a different starting character for these messages, how about a [ ? Follow the start of the string by a real word: not ok 1 [fail] Failed test in foo.t line 2 ok 2 [fatal] WHOA! The fabric of the universe just broke down! [damn it, Jim, I'm a doctor, not a programmer!] This should never happen! Please contact the author immediately! It doesn't set it off visually as nicely as the repeated bangs, but that's not the goal here. People want to read this stuff programmatically. :)
Re: No, sending diag() to STDOUT won't work. Yet again.
In article [EMAIL PROTECTED], Michael G Schwern [EMAIL PROTECTED] wrote: Piping all diagnostics to STDOUT solves nothing except maybe allowing runtests to display warnings again. You still can't tell the difference between a comment (what currently is # foo printed to STDOUT) and a failure diagnostic (what currently is # foo printed to STDERR) and diagnostics associated with a TODO test (which is # foo printed to STDOUT). I'm not advocating any change here because I'm perfectly happy with what we have now, but isn't the problem there that # means too many things? If a comment started with a # (because this is perl), and other things had some other sigil, would anyone be arguing about which filehandle they are on? Again, I'm not saying that anyone should do any work to change this, but after reading the links Schwern provided and checking the wiki, it seems that people talk about the format of the diagnostic but not the thing to signal it.
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Eric Wilhelm [EMAIL PROTECTED] wrote: Are you saying that you want a per-author META.yml or that you don't want to have to say don't send me mail in two places in each distribution, or both? I'm not proposing anything. I think I siad that before. I just don't want to set the same options for every tool that people invent. If my distro has a META.yml and I don't want to get any mail about that module, for instance, I only want to turn off the mail option in one place.
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26] I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all. So, for some subset of META.yml settings, you could consult the module's author settings, found at (say) $MIRROR/authors/.../RJBS/METAMETA.yml Something like that? I feel a potentially irrational sense of dread. I'm not even sure what you mean by that, and it certainly isn't anything I'm talking about. I'm just saying that setting configuration options per tool isn't the way to handle global preferences.
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-03-03T13:31:15] In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: extensions: CPAN::Reporter: cc_author: 0 I think in some cases this might work, but I can imagine options that I'd want, such as cc_author, that future modules or tools might use. I won't know of them a priori, but it's likely that my answer to them will be the same. If you don't know that CPAN::Reporter uses extensions/CPAN::Reporter/cc_author, you won't know that it uses cc_author, either. I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all.
Re: a safer way to use no_plan?
In article [EMAIL PROTECTED], Eric Wilhelm
[EMAIL PROTECTED] wrote:
At the bottom of a test file:
{my $finish = 1; END {$finish or die \n unplanned exit}};
Yeah, you have to remember to put it at the end of the file, but it may
be easier than counting tests. Thoughts?
You don't have to remember to put it at the bottom of the file if you
start with a template. :)
I run into problems where a loop runs fewer iterations than it should
but the test script otherwise runs to completion normally.
That's also a problem for the just run it and see argument. Sure, it
works for simple things, but when you get into hundreds or thousands of
tests, it's difficult to know if the humber you ran is the number you
were supposed to run. (This often is the case when I'm running
something that has several boundary conditions and I'm running every
combination of those. The factorials get big quick :)
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * David Golden [EMAIL PROTECTED] [2007-02-28T22:39:01] Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. Why not: extensions: CPAN::Reporter: cc_author: 0 I think in some cases this might work, but I can imagine options that I'd want, such as cc_author, that future modules or tools might use. I won't know of them a priori, but it's likely that my answer to them will be the same. This proposal might be fine for some things that want to encapsulate some settings, but I predict there'll be some overlap if this ever gets popular.
Re: UNIVERSAL::require broke my tests
In article [EMAIL PROTECTED], Ovid [EMAIL PROTECTED] wrote: Note that the following does not trigger this: use UNIVERSAL::require; use CGI qwno_such_function; CGI has the nifty feature of auto-generating functions from its import list to turn them into HTML generating functions: use UNIVERSAL::require; use CGI qwno_such_function; print no_such_function( Hello ); The output is: no_such_functionHello/no_such_function
Re: use mocked
In article [EMAIL PROTECTED], Luke Closs [EMAIL PROTECTED] wrote: On 2/23/07, A. Pagaltzis [EMAIL PROTECTED] wrote: * Dominique Quatravaux [EMAIL PROTECTED] [2007-02-23 11:35]: And, uh, how about this: use lib 't'; use mock::LWP::Simple; That will not call the importer in the right package. To expand on this answer, without funky voodoo, after loading mock::LWP::Simple perl won't think it had loaded LWP::Simple. That's not so hard to fix though. The mock class just needs to know how to tell Perl it's already loaded whatever its mocking. It's not that funky, at least compared to what the proposed pragma does.
Re: Integrating Test::Run into an ExtUtils::MakeMaker+Test::Manifest Setup - Take 2
In article [EMAIL PROTECTED], Shlomi Fish
[EMAIL PROTECTED] wrote:
http://svn.perl.org/modules/XML-RSS/trunk/Makefile.PL
You have:
--
{
package MY;
sub test_via_harness {
my($self, $perl, $tests) = @_;
return qq|\t$perl -MTest::Manifest | .
qq|-e run_t_manifest(\$(TEST_VERBOSE), '\$(INST_LIB)', | .
qq|'\$(INST_ARCHLIB)')\n|;
}
}
-
but you get that for free with:
eval use Test::Manifest
You also have:
'PREREQ_PM'= {
'Test::Manifest' = '0.9',
But that's a really old version. Try something later than 1.14.
Re: ExtUtils::MakeMaker, and t/ sub-directories
In article [EMAIL PROTECTED], Andy Lester [EMAIL PROTECTED] wrote: On Feb 8, 2007, at 1:26 AM, Nik Clayton wrote: [ I vaguely recall a discussion about this, but my search-fu is weak, and I can't find it ] Is there a standard way/idiom to get ExtUtils::MakeMaker to support tests in subdirectories of t/? I've got a bunch of tests, and rather than client-ls.t, client- add.t, client-commit.t, etc, I'd like t/client/ls.t, t/client/ add.t, t/client/commit.t, and so on. No, there's not a way for MakeMaker to do it. Look at how I handle it in WWW::Mechanize, where I have t/live, t/static, etc. Sure there's a way to get MakeMaker to do it. You just have to tell it how to find the test files, as I do in Test::Manifest.
Re: ExtUtils::MakeMaker, and t/ sub-directories
In article [EMAIL PROTECTED], Nik Clayton [EMAIL PROTECTED] wrote: Is there a standard way/idiom to get ExtUtils::MakeMaker to support tests in subdirectories of t/? I don't know of a standard idiom, but I created Test::Manifest so I didn't have to live with MakeMaker's method of getting test files, which is just globbing t/. IF you don't like the way that I do it in Test::Manifest, just follow the example to override the parts that discover the test files. Although Andy says that MakeMaker can't do it, MakeMaker has a built-in extension mechanism with the MY::* namespace to override parts of itself.
Re: Test::Harness 3.0
In article [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED] wrote: Adam Kennedy wrote: So, seeing as you are going to take over Test::Harness as well, is NOW where I ask you for the PITA-related capturing of a copy of the TAP streams? :) Let me just clarify what I'm wanting here, for those talking about alternative parsing. I don't want ANY difference in testing behaviour. I want the testing to all behave as normal. I just want an ADDITIONAL copy of the TAP output dumped for me. Yes, please keep all those things. Do all the research and development you like but realize that the world stills needs module installation to work. Most Perl porgrammers have no idea you're about to make this big change, whatever the change is.
Re: CPAN::Shell-install() downloads dependencies, but doesn't add them to @INC for tests
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Florian Scharinger [EMAIL PROTECTED] wrote: Hi David, any pointer how I can create a custom Bundle:: ? The documentation of CPAN.pm defines the Bundle format, or you can look at existing Bundle:: modules and just change it to be what you need. If you have a setup that you already like, the cpan(1) tool can create a bundle file representing your local installation: % cpan -a From there, edit to taste. Good luck :)
Re: recursive_test_files in Module::Build and in ExtUtils::MakeMaker
In article [EMAIL PROTECTED], David Golden [EMAIL PROTECTED] wrote: On 11/2/06, Chris Dolan [EMAIL PROTECTED] wrote: It's not an EU::MM bug -- it's a new M::B feature. What should you do? You're not going to like this answer: Don't use recursive test directories. :-) Does Test::Manifest support nested test files? If so, that might be an alternative. I'm not sure what nested means, but Test::Manifest just takes a list of files in t/test_manifest and passes them to run_all_tests. You can put whatever you like in test_manifest, although all pathnames are relative to t/. I have thought about a `make testmanifest` that would work like `make manifest`, but I haven't really needed it. If I have a lot of files, I just : $ find . -name *.t test_manifest I think the latest version of Test::Manifest has support for primitive #include like behavior, so the test_manifest might reference other files that include other lists of tests, recursively. If it's not on CPAN, I'll have to take my local copy and upload it.
Re: Integrating Test::Run into an ExtUtils::MakeMaker+Test::Manifest Setup
In article [EMAIL PROTECTED], Shlomi Fish [EMAIL PROTECTED] wrote: See http://xrl.us/sw5o for a recipe for integrating make runtest and make distruntest targets into a Makefile.PL-generated Makefile that makes use of Test::Manifest. That Test::Manifest stuff in XML::RSS is old. Instead, you can just say: eval use Test::Manifest 1.14; However, if you are doing odd test things, you probably don't want to use Test::Manifest. Just write your own thing to run the tests.
Re: AnnoCPAN Doc Patch Maker
In article [EMAIL PROTECTED], Chris Dolan [EMAIL PROTECTED] wrote: On Oct 3, 2006, at 3:58 PM, brian d foy wrote: Even better would be something like Pod::Spellchecker. I've started the project several times but never had that much motivation to finish it. Things would be simple if it could just spell-check everything, but I want it to be able to skip verbatim blocks, things in C, and so on. It's not an especially tough problem, just not as fun for me as other not especially tough problems. Happily, this problem has already been solved! Not really. :) The spell checking is done by external programs, and the Pod::Spell module outputs something that doesn't have all of the original docs in it. You can find out if there are spelling errors, but you don't get back something that fixes it, and it's not interactive.
Re: Proposal for author test envvar standard (was Re: Suggestions for cpantesters)
In article [EMAIL PROTECTED], Chris
Dolan [EMAIL PROTECTED] wrote:
On Oct 3, 2006, at 11:13 AM, David Golden wrote:
Given what you use, perhaps qr/AUTHOR_TEST/ is a good idea.
That's cool. Then I could do Cif ($ENV{AUTHOR_TEST_CDOLAN}){ ... }
in my .t files and just set that to 1 in my .cshrc for all time.
I do this with Test::Manifest. In the t/test_manifest file I list the
tests and the testing level after each test (with a default of 1)
load.t
pod.t 2
pod_coverage.t 2
prereq.t 3
feature.t
I then set the environment variable TEST_LEVEL to the level I want. If
I set it to 2, it runs everything with that level and lower, so all the
tests with 2 and 1.
In a couple of modules, I even create the t/test_manifest dynamically.
I can distribute all the tests but only use some of them.
Re: AnnoCPAN Doc Patch Maker
In article [EMAIL PROTECTED], chromatic [EMAIL PROTECTED] wrote: Wouldn't it be nice to be able to pull up a text entry box online with the contents of the POD, fix any typos inline, then submit it to the server which can generate a patch and perhaps redirect me to rt.cpan.org? I think I'd submit more doc patches that way. Even better would be something like Pod::Spellchecker. I've started the project several times but never had that much motivation to finish it. Things would be simple if it could just spell-check everything, but I want it to be able to skip verbatim blocks, things in C, and so on. It's not an especially tough problem, just not as fun for me as other not especially tough problems.
Re: CPANTS quality brainstorming
In article [EMAIL PROTECTED], Thomas Klausner [EMAIL PROTECTED] wrote: I added a few things, most notably the new has_license metric (thanks again to Gabor Szabo for implementing it). (BTW, there was quite a drop in the CPANTS game highscore lists, as lots of dists don't come with a license (9064 to be exact) Well, you should say that those dists don't come with a license that you detected. For instance, all of my modules clearly state in the documentation that they are available under the same terms as Perl itself. They come with a license, even if its not explicity stated in META.yml. Furthermore, everything has a license, even if it is implied. Since everything on CPAN is available for free, no one has to pay any fee or enter into any agreement to use anything on CPAN. If we find a distribution that says otherwise, we (as in the PAUSE admins) remove it from CPAN. How about some other ways to measure this metric? Let's not divide the world into people who use Module::Build and those who don't. Makefile.PL still drives most distributions, and, at least for me, I've never received a complaint that dealt with a Makemaker issue.
Re: post-YAPC::Europe CPANTS news
In article [EMAIL PROTECTED], Chris Dolan [EMAIL PROTECTED] wrote: On Sep 12, 2006, at 9:24 AM, Salve J Nilsen wrote: Any metric that catches bad things, particularly bad technical things, is going to be just fine. Metrics that try to push good behavior are fraught with trouble, because they start pushing people in odd directions. Do you have an example on this? (Any pointer would be wonderful.) I have two: pod.t and pod_coverage.t. These are pointless to run on an end-user's machine. At best they are redundant to immutable tests already run on the author's machine and just waste processor cycles. I've actually discovered POD problems when users run these tests. They aren't immutable because people use different versions of tools and different versions of the various POD modules. With simple fixes, I can make some things readable by people even with old Perl distributions. Having said that, I still find value in them. If the installer watches the tests go by, they see that the documentation is being tested. I hope that gives them a little more confidence in the module. And, since this is open source, I distribute all the source I use to develop the module. That's the idea, isn't it? If the user changes something, they still have all the tests, including one to remind them to document their new function using the proper format. :)
Re: CPANTS quality brainstorming
In article [EMAIL PROTECTED], Adriano Ferreira [EMAIL PROTECTED] wrote: On 9/13/06, Thomas Klausner [EMAIL PROTECTED] wrote: Maybe it would be reasonable to also check for a POD-Heading named LICENSE, but that's definitly more error-prone. Tell one place where people should look to have a bunch of information about a Perl dist? META.yml, Makefile.PL, Build.PL, README, the sources, etc. do not look like a good answer. A simple one would be desirable. Thinking about this further and talking to a few people about it, the only place that makes any sense is the source code file itself. After installation, the rest of the distribution will disappear. The license has to stay with the source. I think this is mostly a solved problem, though. The people who really care about this stuff have this enormous preambles in the source that shows the license. http://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude
Re: Query: Perl Testing
In article [EMAIL PROTECTED], Adrian Howard [EMAIL PROTECTED] wrote: On 25 Aug 2006, at 09:04, Vishal Mehta wrote: [snip] 1) What is the role of Perl in testing? [snip] It's a programming language. People use perl to test programs written in perl. People use Perl to test. No need to say what they test. Plenty of people use Perl to test programs written in any other language, or even to test hardware, networks, and other non-programmy sorts of things.
Re: CPANDB - was: Module::Dependency 1.84
In article [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED] wrote: Nobody would care about dependencies if they never failed (except for the issue of installation time). I have a couple of clients that are very skittish about outside dependencies in general. They have to get thrid-party code legally approved, etc, and since they can already use Perl they don't need any special permission to use those modules. One client specifically wasn't allowed from CPAN (although we solved that with a minicpan on a disk). I don't make up these rules, but they are out there. For the CPANDB, as long as I can read the data it in my own program, I don't much care what CPAN::Index uses.
Re: CPANDB - was: Module::Dependency 1.84
In article [EMAIL PROTECTED], Tels [EMAIL PROTECTED] wrote: I am not sure what stupid consists, but my system wouldn't have problems handling 512 MB of memory. I'd prefer that you not decide that my system needs 512Mb to use this, even if you can handle that on your side.
Re: CPANDB - was: Module::Dependency 1.84
In article [EMAIL PROTECTED], Tels [EMAIL PROTECTED] wrote: My real-grand-plan was always to have a CPANDB module that does exactly the following: I think the latest version of my cpan(1) script does everything you show, although it doesn't use a local database. It would be nice to have all of that locally so any program could use it.
Re: YAML and Makefile.PL (was various topics)
In article [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED] wrote: The big advantage I see here is it's not you doing the work, it's everybody else. I generally don't have too much of a problem doing incrementals... cd trunk/Module-Name ppichangeversion 0.14 0.15 perl ../../tools/build_cpan.pl --install --commit --upload Module-Name Incremental releasing is a toolchain problem. You can automate the thing down to a single command if you care enough. (even if it's a bit at a time) And aren't you writing Module::Release or something to do exactly that? Module::Release does do all of that, but that doesn't mean I let it blindly do its thing or that I want to upload 50 new dists to CPAN when none of them change anything in the real code.
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
In article [EMAIL PROTECTED], demerphq [EMAIL PROTECTED] wrote: On 1/30/06, David Cantrell [EMAIL PROTECTED] wrote: Adam Kennedy wrote: A testing system should only be sending FAIL reports when it believes it has a platform that is compatible with the needs of the module, but when it tries to install tests fail. So how, then, do I tell the testing system this module only works on Unix-like filesystems on Unix-like OSes? Hopefully it will be something like: $I::don't::bother::to::write::portable::code=1; ;-) Seriously though, I would expect things in Win32::* to only work on Windows, things in Linux::* only to work on linux, and so on for many other sections (including Mac::* where I have some modules). Portable code isn't always the goal.
Re: YAML and Makefile.PL (was various topics)
In article [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED] wrote: And if there is a problem with Module::Install, you have to update all your dists with the new version - solve one problem, create two new ones :) But if there is a problem with EU::MM or Module::Build, you have to update every installation in the entire world with the new version. That's not entirely fair. If I personally had to update all of my distributions and re-upload them to CPAN, it would never get done. If I (or the other users) have to upgrade EU::MM or Module::Build, they just install the latest from CPAN. If I had the old versions in my dist, I would have configured @INC to look for them, and that's where they'd be found regardless of what else is installed. I could code all sorts of conditionals to check if the module is already installed and of the right version and so on, but then things are getting pretty complex. It would be nice if some of these modules could do their magic at `make dist` time so they didn't have to show up in the dist. :)
