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)" 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 <20111206123211.gf18...@bytemark.barnyard.co.uk>, David Cantrell wrote: > On Mon, Dec 05, 2011 at 06:21:13PM -0600, brian d foy wrote: > > In article <20111205154758.gh17...@bytemark.barnyard.co.uk>, David > > Cantrell 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. > > Various backpan mirrors seem to have different 02packages files. In > general you can't rely on them to be the same as CPAN's. Well, that's true, but not at all what I was saying. CPAN's index is also BackPAN's index. Take the CPAN index and use it with a BackPAN mirror and it's the same thing. You're confusing this by using something that is not CPAN's index, like an out of date copy that might be on BackPAN. Part of the confusion most people have stems from CPAN.pm, et alia insisting on fetching the index from the same place it will fetch the modules.
Re: Need suggestions for terminology
In article <20111205154758.gh17...@bytemark.barnyard.co.uk>, David Cantrell 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.
Re: TB2::Mouse will be internal use only... with one hitch.
> This doesn't work. Mouse doesn't see the superclass's attributes because they > were declared by a different namespace, TB2::Mouse. The subclass must use > TB2::Mouse if it wants to override attributes. I hadn't realized that. It > also must use TB2::Mouse if it wants to consume TB2 roles. Well, there's another option. Don't use any sort of Mouse. I know that you wanted to save a lot of development work, but the trade-offs seems to be mucking up everything. It seems to me that you're forcing the issue and we're going to end up with something that's as fragile and unworkable as what we had before. You have a lot invested, and sometimes that makes it hard to dump work when it should be dumped. I'm not saying that you should dump Mouse, but when I see a design decision reach this far into the world (when nobody should have ever noticed it), I generally think it's time to consider if it was really a good idea. However, I have no experience with TB2 development. As a person who will have to subclass TB2, I'm really not looking forward to any of this. I shouldn't have "to deal" or even know about the TB2 internals. Is there anyway that you can create a subclassing interface so I don't have to know? use TB2::Subclasser; my $subclass = TB2::Subclasser->new( ... ); I won't think much harder on that because I start thinking about Self and how much I'd rather have that system over Python's. :)
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
Re: RFC: Private CPAN In A Box
In article , David Golden 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: RFC: Private CPAN In A Box
In article <02c001cc1a59$6865b810$39312830$@activestate.com>, Jan Dubois 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: 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 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 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
On Tue, May 4, 2010 at 6:07 PM, Jan Dubois 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 http://www.pair.com/~comdog/
Re: Toolchain issues
In article , David Golden 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: 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 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.
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: The Test Feature I Want
In article <200812121032.00515.enoba...@gmail.com>, Eric Wilhelm 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.
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: 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: passing the baton onwards
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? Beyond that, is there a way for everyone to see the list of those modules? That's what I meant about you changing pause, much like you did for 06.perms. It would also be nice to see that bit set somewhere like CPAN Search, maybe with a button that says "I want to take over maintenance". None of this happens any differently than before. Either we need fore-knowledge that the author has decided to move on in life, or our waiting period for public notification. I'll do the work to handle the ones the authors give up without a maintainer, and my first idea was that a virtual user than we advertised as "free modules" (free as in kittens) would move modules int willing homes faster. But then, maybe not. -- brian d foy (one of many PAUSE admins), http://pause.perl.org archives at http://www.xray.mpe.mpg.de/mailing-lists/modules please send all messages back to [EMAIL PROTECTED]
Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)
In article <[EMAIL PROTECTED]>, Andy Lester <[EMAIL PROTECTED]> wrote: > Where's the warning on the front page of PAUSE saying "Your upload had > better match certain criteria or else we will send you mass email > about it"? PAUSE sends you email too, but only for PAUSE things, such as indexer failure, upload, or deletion reports. I've received more mail from PAUSE in the last month than from CPAN Testers. PAUSE, however, has an explicit policy of not caring about the quality of whatever people upload, and we encourage people to upload early rather than later. We don't make those judgements, and we're not going to. CPAN Testers is what happens in a world of open source. Anyone gets to look at and comment on your code, whether you agree with them or not, and they don't need anyone's permission.
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: 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: 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: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)
In article <[EMAIL PROTECTED]>, David Cantrell <[EMAIL PROTECTED]> wrote: > What I'm not willing to do, however, is to manually check every report > and ensure perfection I don't think CPAN Testers should manually check every report, but I would like them to do something a bit more cautious with new setups or when the failure rate in a certain time period is too high (for whatever high is). Once a setup seems to work, just let it go on its own. :)
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: 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' / 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: 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'
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: 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 :)
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. :)
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: 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: 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: expanding the cpan script, and Module
[[ 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: > Desrired Behavior: > running a cpan session, with the flag set, will cause the session to > note the error and > not go any further If you're talking about my cpan(1) script, I guess that can be a feature. > Would a Patch Be Acceptable? Send me the patch through RT for the queue "cpan-script". 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: > 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
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: 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: [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: [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: 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: 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: 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: Searching CPAN repositories in a chain
In article <[EMAIL PROTECTED]>, Matisse Enzer <[EMAIL PROTECTED]> wrote: > I'd like to be able to; > check mirror-list-number-one (probably all private, inside our > firewall) > check mirror-list-number-two This sounds like the normal behavior of CPAN.pm with a little CPAN::Mini::Inject magic. Check out my latest perlcast and the slides from my recent CPAN talk to LA.pm, as well as my CPAN article in the latest issue of The Perl Review. Good luck :)
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: 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]>, 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: add points for registered namespaces
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article <[EMAIL PROTECTED]>, Christopher H. Laco <[EMAIL PROTECTED]> wrote: > Do we even register namespaces any more? I tried 3 years ago with Handel > and never heard anything. We still register namespaces. I don't see that you ever submitted Handel for registration, although you did submit Business::Commerce. If you register Handel now, I'll just approve it. I'm actually surprised it didn't already happen because we had already talked about that name and I remember liking it. :)
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: a "standard" place for extra tests
In article <[EMAIL PROTECTED]>, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > # from brian d foy > # on Saturday 18 August 2007 01:33 pm: > > > 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. > > Or override nothing and simply group the tests into directories. Well, if you want some directories to be special, simply grouping tests into directories isn't going to get you anything. :)
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: 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: 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: 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: 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: 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: Eliminating STDERR without any disruption.
In article <[EMAIL PROTECTED]>, Michael G Schwern <[EMAIL PROTECTED]> wrote: > Andy Armstrong wrote: > > I'm still not clear what this notation provides that we can't do with > > the new YAML machine readable diagnostic syntax. What are the supposed > > benefits? Concision? > > Yeah, brevity. Pretty much. And human readability. And line-oriented output is extremely easy to work with. It would be very nice if we could easily work with a TAP stream in a user script with just the stuff the comes with Perl.
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: Paying for TAP 2.0
In article <[EMAIL PROTECTED]>, Christopher H. Laco <[EMAIL PROTECTED]> wrote: > Paul Beckingham wrote: > > I'm wanting sparse output: > > > > 1..100 sparse > > 12 not ok > > 83 not ok > > > But how do you know "23 ok" if you were never told that it ran ok? For your sparse driver, it's just not emiting the "ok" messages. It's no different at the test level (or, doesn't have to be). This would be the same as filtering the current test output to get only the lines with "not" in 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: 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: > * 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: 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 qw; 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 qw; print no_such_function( "Hello" ); The output is: Hello
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]>, 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: 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: 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: Uses for TAP beyond just testing...
In article <[EMAIL PROTECTED]>, Adam Kennedy <[EMAIL PROTECTED]> wrote: > It seems to me that the features of TAP and Test::More combined (the > ability to be both human and machine-readable and the ability to > conveniently test as I go along) are almost ideal for writing these > sorts of deploy scripts. I have thought, from time to time, that Module::Release could be a Test::More like thing, except that any failure should stop everything. However, it doesn't really make anything better, so I haven't done the work. :)
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: 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: Pod Spelling
In article <[EMAIL PROTECTED]>, Ivan Tubert-Brohman <[EMAIL PROTECTED]> wrote: > 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." > Have you tried Pod::Spell and Test::Spelling? I think they already do that. I tried those a long time ago. I wanted something interactive that doesn't rely on external programs.
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: 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: 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 C > 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: CPANTS quality brainstorming
In article <[EMAIL PROTECTED]>, David Golden <[EMAIL PROTECTED]> wrote: > brian d foy wrote: > > 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. > Nit -- .pod files also stay around and could contain thinks like licenses. The license has to be in every file that contains code. If you ship the file somewhere, it code in that file comes with the license.
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: 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]>, 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: 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: > 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.
