On Jul 31, 2007, at 1:16 AM, Michael G Schwern wrote:
* POD tests should be run by the user.
* POD tests should not be run by the user.
Anything productive come out of it?
I don't care which people choose, as long as it's done on CentOS
Linux with vim, uses spaces instead of tabs, and uses
Long threads scare me and, I'm sure, other people. Can people sum up what
useful things have been said in that long thread? Skimming it so far it seems
to be:
* POD tests should be run by the user.
* POD tests should not be run by the user.
Anything productive come out of it? Perhaps the argum
# from David Golden
# on Monday 30 July 2007 07:39 pm:
>On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> `mkdir at`, but I fail to understand the resistance.
>
>* CPANTS Kwalitee
>* Module::Starter
Both need correcting anyway.
>* Test::Pod::Coverage
Why does that matter? Does it care whe
On Monday 30 July 2007 19:39:55 David Golden wrote:
> I admire your desire to engineer a better solution, but there is a lot
> of inertia in the existing tools. And, yes, they can be customized,
> but few people do.
Easy solution: STOP REWARDING PEOPLE TO SHIP AND RUN THE STUPID POD TESTS WITH
On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> `mkdir at`, but I fail to understand the resistance.
* CPANTS Kwalitee
* Module::Starter
* Test::Pod::Coverage
* ExtUtils::MakeMaker
* Module::Build
I admire your desire to engineer a better solution, but there is a lot
of inertia in the exist
# from David Golden
# on Monday 30 July 2007 05:03 pm:
>>Or,
>> simply the hardcore CPAN author who put it in their .bashrc and
>> forgot about it
^-- who will it bite first, will it be him, her, or me?
>> until some broken pod appeared in the middle of a
>> big dependency stack. Environmen
On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> Who knows when you'll run into a box in the publishing industry which
> just happens to be setup for AUTHOR_TESTING some other system. Or,
> simply the hardcore CPAN author who put it in their .bashrc and forgot
> about it until some broken pod
# from Christopher H. Laco
# on Monday 30 July 2007 01:35 pm:
>If it fails and you can't install it, then don't.
>Arguments about whether the tests should or shouldn't be run [or
>included at all] is irrelevant. Tests failed. Don't install.
I think you're looking at this as "oh, I'll try whiz-ba
# from chromatic
# on Monday 30 July 2007 01:39 pm:
>On Monday 30 July 2007 13:19:56 Christopher H. Laco wrote:
>> Eric Wilhelm wrote:
>> > If *you* don't have Test::Pod, and *I* do, *I* cannot install your
>> > module if the pod doesn't pass.
>>
>> Huh? In that code, no Test::POD = skip all tests
# from David Golden
# on Monday 30 July 2007 01:06 pm:
># pod-coverage.t
>use Test::More;
>plan skip_all => "Skipping author tests" if not $ENV{AUTHOR_TESTING};
>
>my $min_tpc = 1.08;
>eval "use Test::Pod::Coverage $min_tpc";
>plan skip_all => "Test::Pod::Coverage $min_tpc required for testing
No
On 30 Jul 2007, at 23:22, David Golden wrote:
There was a coverage failure on a hidden ._Bedford.pm. I'm guessing
that was some editor swap file, but somehow, it got packaged and
distributed.
Mac OS resource fork I think.
--
Andy Armstrong, hexten.net
On 7/30/07, Christopher H. Laco <[EMAIL PROTECTED]> wrote:
> Sure, Test::Pod::Coverage could fail for some reason other than it's
> main purpose of checking coverage and finding a naked method, but so
> then can Test::More and any other test module.
Ironically, that just happened today with Statis
Eric Wilhelm wrote:
> # from Christopher H. Laco
> # on Monday 30 July 2007 11:14 am:
>
>> I don't agree. What runs when I do 'make test' is up to me, and if I
>> want to litter it up with 'author' tests, then that's my business;
>> right or wrong. Don't like it, then don't use my modules. (I stil
On Mon, Jul 30, 2007 at 10:01:12PM +0100, Andy Armstrong ([EMAIL PROTECTED])
wrote:
> Everything you'd use if you were the developer of the module should
> be shipped - because the person to whom it is shipped may turn out to
> be an additional developer of the module.
Right, and once boilerp
On 30 Jul 2007, at 21:26, Andy Lester wrote:
You can't disagree. It's a statement of fact that RJBS and I did
not intend for boilerplate.t to actually get shipped with the module.
Bah - sucked me in too :)
Everything you'd use if you were the developer of the module should
be shipped - bec
On Jul 30, 2007, at 3:06 PM, David Golden wrote:
In case anyone is inspired to update the Module::Starter (or other)
boilerplate, I'm attaching my standard pod-coverage.t and recommending
it as a more robust approach than the existing boilerplate. Set
minimum module versions as necessary for y
On Monday 30 July 2007 13:19:56 Christopher H. Laco wrote:
> Eric Wilhelm wrote:
> > If *you* don't have Test::Pod, and *I* do, *I* cannot install your
> > module if the pod doesn't pass.
> Huh? In that code, no Test::POD = skip all tests. How does that equate
> to an install failure for anyone.
On Jul 30, 2007, at 2:46 PM, A. Pagaltzis wrote:
Certainly, the intent is to have boilerplate.t NOT get shipped
with the module.
Disagree. The tarball should contain the full source necessary to
recreate everything the author did. Stuff that’s not relevant to
end-user installation of the mod
Eric Wilhelm wrote:
> # from Christopher H. Laco
> # on Monday 30 July 2007 11:14 am:
>
>> I don't agree. What runs when I do 'make test' is up to me, and if I
>> want to litter it up with 'author' tests, then that's my business;
>> right or wrong. Don't like it, then don't use my modules. (I stil
On 7/30/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I agree. If I'm going to produce a patch for someone I want to run
> the author tests before I submit it.
Including the tests but leaving them disabled is my preferred
approach. It is trivial to subclass Module::Build to set the
appropriate
On 30 Jul 2007, at 20:46, A. Pagaltzis wrote:
* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 21:41]:
On Jul 30, 2007, at 1:58 PM, Eric Wilhelm wrote:
Thus, I posit that the quality of the module is generally
lower if 'boilerplate.t', 'pod-coverage.t', and 'pod.t'
*exist*.
Certainly, the inten
* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 21:41]:
> On Jul 30, 2007, at 1:58 PM, Eric Wilhelm wrote:
>
> >Thus, I posit that the quality of the module is generally
> >lower if 'boilerplate.t', 'pod-coverage.t', and 'pod.t'
> >*exist*.
>
> Certainly, the intent is to have boilerplate.t NOT get
On Jul 30, 2007, at 1:58 PM, Eric Wilhelm wrote:
Thus, I posit that the quality of the module is generally lower if
'boilerplate.t', 'pod-coverage.t', and 'pod.t' *exist*.
Certainly, the intent is to have boilerplate.t NOT get shipped with
the module.
--
Andy Lester => [EMAIL PROTECTED] =
# from Christopher H. Laco
# on Monday 30 July 2007 11:14 am:
>I don't agree. What runs when I do 'make test' is up to me, and if I
>want to litter it up with 'author' tests, then that's my business;
> right or wrong. Don't like it, then don't use my modules. (I still
> think all author tests shou
Eric Wilhelm wrote:
> # from David Golden
> # on Monday 30 July 2007 05:34 am:
>
>> The issue at hand is really *release* testing (i.e. did I bump the
>> version, did I test my Pod, do I use good style, etc.) being mixed
>> with *functional* testing -- and the corresponding push for release
>> tes
* Christopher H. Laco <[EMAIL PROTECTED]> [2007-07-29 17:05]:
> A failing pod test is the first sign pod2* generation is
> broken. It's rare, but I've been in the situation where for
> some reason (mistmatching dist requirements, failed upgrades,
> bad dist packages, broken troff, etc) the creation
On Monday 30 July 2007 10:01:25 Eric Wilhelm wrote:
> I think the important bit is that `make test` only runs tests which
> verify the module's functionality.
... and if my POD coverage somehow mysteriously changed between the time I
bundled a new dist and some user downloaded that bundle from t
# from David Golden
# on Monday 30 July 2007 05:34 am:
>The issue at hand is really *release* testing (i.e. did I bump the
>version, did I test my Pod, do I use good style, etc.) being mixed
>with *functional* testing -- and the corresponding push for release
>testing modules being included as req
On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> aspersions on a great module. The Test::Exception/Sub::Uplevel problem
> causing false negatives was always a bit frustrating for me and it came
> out in the last email.
>
> I'm sorry if I offended you :(
Apology accepted. It frustrated me so much I w
--- David Golden <[EMAIL PROTECTED]> wrote:
> On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> > We also have dependencies on Sub::Uplevel (a notorious source of
> build
> > problems),
>
> Excuse me? CPAN::Testers for Sub::Uplevel 0.14: PASS 165 FAIL 0
>
> There was a time when Test::Exception had
On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> We also have dependencies on Sub::Uplevel (a notorious source of build
> problems),
Excuse me? CPAN::Testers for Sub::Uplevel 0.14: PASS 165 FAIL 0
There was a time when Test::Exception had things in build_requires
that should have been in requires.
--- demerphq <[EMAIL PROTECTED]> wrote:
> On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> > Tests should *only* fail when there is a clear, unequivocal reason
> to
> > believe that the code will not function appropriately on someone's
> > machine. Having '=head0' or a '=back' without '=over' should
* David Cantrell <[EMAIL PROTECTED]> [2007-07-30 12:04]:
> Eric Wilhelm wrote:
> ># from Adam Kennedy
> >>Thus, I would like to propose the following.
> >>1. That the running of POD-related tests by end users is
> >>considered harmful.
> >+20
>
> -40
>
> I don't see that it's harmful at all. It's
On 7/30/07, Ovid <[EMAIL PROTECTED]> wrote:
> Tests should *only* fail when there is a clear, unequivocal reason to
> believe that the code will not function appropriately on someone's
> machine. Having '=head0' or a '=back' without '=over' should not be
> such a failure. It's taken a lot of grie
--- David Cantrell <[EMAIL PROTECTED]> wrote:
> Eric Wilhelm wrote:
> > # from Adam Kennedy
> >> Thus, I would like to propose the following.
> >> 1. That the running of POD-related tests by end users is
> considered
> >> harmful.
> > +20
>
> -40
>
> I don't see that it's harmful at all. It's n
Eric Wilhelm wrote:
# from Adam Kennedy
Thus, I would like to propose the following.
1. That the running of POD-related tests by end users is considered
harmful.
+20
-40
I don't see that it's harmful at all. It's not even particularly
harmful (merely annoying) for an author to add Test::Po
36 matches
Mail list logo
