* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 22:30]:
> 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 a
* David Golden <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> On 7/31/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> > >* Test::Pod::Coverage
> >
> > Why does that matter? Does it care where its .t file lives?
>
> The synopsis suggests t/pod-coverage.t.
Wow, now that is *incredible* inertia right ther
* David Cantrell <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> A. Pagaltzis wrote:
>
> >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 module should simply
> >be kept out of the way.
Eric Wilhelm wrote:
# from David Cantrell
Let us assume that I write a module that, if you have a particular
module installed will do some extra stuff. This is very common.
...
Skipping tests because you correctly identify that the optional module
isn't available is, of course, counted as passi
# from David Cantrell
# on Wednesday 01 August 2007 03:21 am:
>>> Wrong. If AUTHOR_TESTING then surely all tests *must* pass both
>>> with and *without* the optional module!
>>
>> What good does it do to skip the test if AUTHOR_TESTING? That just
>> gets us back into the same situation as the cu
Adam Kennedy wrote:
Salve J Nilsen wrote:
Anyhow, I think being able to recreate the entire distribiution may be
a good thing, but perhaps not necessarily from a CPAN-distributed
tarball. I'd certainly expect that from a source repository checkout,
though.
CPAN-distributed tarballs are the p
Eric Wilhelm wrote:
# from David Cantrell
No. If AUTHOR_TESTING, fail miserably unless the pod and coverage
both 1. gets tested and 2. passes. That means the Test::Pod::*
module in question must load.
Wrong. If AUTHOR_TESTING then surely all tests *must* pass both with
and *without* the opti
Eric Wilhelm wrote:
I'm thinking the installer should have the option to scan the tests and
skip any that use qr/Test::Pod(?:::Coverage)?/.
This wouldn't work.
It would just mean that the installer would skip ALL the tests for
Test::Pod :)
There's many cases when testing the Test:: modules
Christopher H. Laco wrote:
I say that's fine. 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. File RT.
Filing RT requires understand what failed and why. This requires
Salve J Nilsen wrote:
Anyhow, I think being able to recreate the entire distribiution may be a
good thing, but perhaps not necessarily from a CPAN-distributed tarball.
I'd certainly expect that from a source repository checkout, though.
CPAN-distributed tarballs are the primary source of the s
chromatic wrote:
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 t
David Golden wrote:
CPAN is a core strength of Perl because it makes developer's lives
easier by not reinventing the wheel.
This is not necesarily the case.
Every language has ways of providing additional libraries that make
developers lives easier by not reinventing the wheel.
CPAN is a co
# from David Cantrell
# on Tuesday 31 July 2007 04:27 am:
>> No. If AUTHOR_TESTING, fail miserably unless the pod and coverage
>> both 1. gets tested and 2. passes. That means the Test::Pod::*
>> module in question must load.
>
>Wrong. If AUTHOR_TESTING then surely all tests *must* pass both wi
On 7/31/07, David Cantrell <[EMAIL PROTECTED]> wrote:
> Steffen Mueller wrote:
>
> > Does this do what you want?
> > http://search.cpan.org/~corion/Test-Without-Module-0.09/
>
> Doesn't do what I want, as I want to be able to "infect" any perl
> processes that might get exec()ed by the one from whi
Adriano Ferreira wrote:
PERL5LIB=MDevel::Hide=Module::ToHide process_that_fork_other_processes.pl
works as far as I know.
PERL5OPT.
Yes, that will do the job, but I want it to be built in to the
module-hiding module rather than something extra that the user needs to
do himself. Would you
Steffen Mueller wrote:
Does this do what you want?
http://search.cpan.org/~corion/Test-Without-Module-0.09/
Doesn't do what I want, as I want to be able to "infect" any perl
processes that might get exec()ed by the one from which I've hidden
Some::Module.
--
David Cantrell
Hi Andy,
Andy Armstrong schrieb:
On 31 Jul 2007, at 12:27, David Cantrell wrote:
Wrong. If AUTHOR_TESTING then surely all tests *must* pass both with
and *without* the optional module!
I'm still stuck on thinking up a decent name for this:
http://drhyde.cvs.sourceforge.net/drhyde/perlmodules
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 intent is to have boilerplate.t
On 31 Jul 2007, at 12:50, Steffen Mueller wrote:
I'm still stuck on thinking up a decent name for this:
http://drhyde.cvs.sourceforge.net/drhyde/perlmodules/No/lib/No.pm?
revision=1.2&view=markup
As per my post of a few seconds ago, how about making it a pragma:
'unavailable'? :)
Does this d
On 31 Jul 2007, at 12:27, David Cantrell wrote:
Wrong. If AUTHOR_TESTING then surely all tests *must* pass both
with and *without* the optional module!
I'm still stuck on thinking up a decent name for this:
http://drhyde.cvs.sourceforge.net/drhyde/perlmodules/No/lib/No.pm?
revision=1.2&view=
On 31 Jul 2007, at 12:19, David Cantrell wrote:
A. Pagaltzis wrote:
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 module should simply be kept out of
the way.
I ever-so-respectful
Eric Wilhelm wrote:
# from David Golden
# pod-coverage.t
use Test::More;
plan skip_all => "Skipping author tests" if not $ENV{AUTHOR_TESTING};
...
No. If AUTHOR_TESTING, fail miserably unless the pod and coverage both
1. gets tested and 2. passes. That means the Test::Pod::* module in
questi
A. Pagaltzis wrote:
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 module should simply be kept out of
the way.
I ever-so-respectfully disagree. I am not going to include the origi
On 7/31/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> >* Test::Pod::Coverage
>
> Why does that matter? Does it care where its .t file lives?
The synopsis suggests t/pod-coverage.t.
David
# 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
# from Christopher H. Laco
# on Sunday 29 July 2007 08:00 am:
>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 of man pages/html from
>the dist pod fails outright.
That reinforce
# from Adam Kennedy
# on Saturday 28 July 2007 01:52 pm:
>Unfortunately, the pod coverage tests requires the module to be
>compiled, so CPANTS can never safely run it, and thus can never run it
>at all. :)
No. *Pod::Coverage* requires the module to be compiled. Testing the
coverage of pod does
Adam Kennedy wrote:
> For background on this email, see the following entry in my journal.
>
> http://use.perl.org/~Alias/journal/33893
>
> Lately, I've noticed a series of modules that are cargo-culting the use
> of test_pod and test_pod_coverage in their tests.
>
> Not only are we seeing spuri
On 7/28/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> * chromatic <[EMAIL PROTECTED]> [2007-07-28 19:10]:
> > Let me also suggest #3: revise the appropriate CPANTS tests to
> > add Kwalitee only if the static analysis tests do *not* run by
> > default.
>
> Maybe deduct points for depencies on obvio
* chromatic <[EMAIL PROTECTED]> [2007-07-28 19:10]:
> Let me also suggest #3: revise the appropriate CPANTS tests to
> add Kwalitee only if the static analysis tests do *not* run by
> default.
Maybe deduct points for depencies on obvious author-testing
distros?
(Although that could get tricky whe
The POD testing I can mostly agree with.
Unfortunately, the pod coverage tests requires the module to be
compiled, so CPANTS can never safely run it, and thus can never run it
at all. :)
Adam K
Eric Wilhelm wrote:
# from Adam Kennedy
# on Saturday 28 July 2007 09:38 am:
Thus, I would like
chromatic wrote:
I use Module::Build (don't jerk your knee yet, Adam) so that I can easily
override 'make disttest' to run my author tests. I keep them in t/author/.
Build.PL for Test::MockObject should make it a little clearer:
http://search.cpan.org/src/CHROMATIC/Test-MockObject-1.
# from Adam Kennedy
# on Saturday 28 July 2007 09:38 am:
>Thus, I would like to propose the following.
>
>1. That the running of POD-related tests by end users is considered
> harmful.
+20
>2. That the test_pod and test_pod_coverage tests by modified, such
> that these tests check for the mentio
On Saturday 28 July 2007 09:38:14 Adam Kennedy wrote:
> For background on this email, see the following entry in my journal.
>
> http://use.perl.org/~Alias/journal/33893
>
> Lately, I've noticed a series of modules that are cargo-culting the use
> of test_pod and test_pod_coverage in their tests.
>
67 matches
Mail list logo
