Salve J. Nilsen wrote:
Let's say Joe Sysadmin wants to install the author's (a.k.a. "your")
module Useful::Example, and during the test-phase one of the POD tests
fail.
Joe Sysadmin doesn't use modules, lets try the following.
"Joe Sysadmin wants to install the JSAN client, because his
HTML/J
# from Yitzchak Scott-Thoennes
# on Tuesday 31 July 2007 10:19 pm:
>On Tue, July 31, 2007 9:56 pm, chromatic wrote:
>> On Tuesday 31 July 2007 20:25:15 Salve J. Nilsen wrote:
>>> Turning off syntax checking of your POD is comparable to not
>>> turning on warnings in your code. Now would you publis
On Tue, July 31, 2007 9:56 pm, chromatic wrote:
> On Tuesday 31 July 2007 20:25:15 Salve J. Nilsen wrote:
>> Turning off syntax checking of your POD is comparable to not turning on
>> warnings in your code. Now would you publish code developed without
>> "use
>> warnings;"?
>
> Now that's just sil
On Tuesday 31 July 2007 20:25:15 Salve J. Nilsen wrote:
> Turning off syntax checking of your POD is comparable to not turning on
> warnings in your code. Now would you publish code developed without "use
> warnings;"?
Now that's just silly.
I really have nothing more to say in this thread. Wow
chromatic said:
>
> Please explain to me, in detail sufficient for a three year old,
> precisely how:
>
> 1) POD can possibly behave any differently on my machine versus anyone
> else's machine, being non-executed text and not executed code
I'll assume the three-year-old is a particularly bright
David Golden wrote:
* Alternatives -- Eric Wilhelm suggests putting these tests in at/ and
running them with prove. Likewise, Module::Build and
ExtUtils::MakeMaker could have targets added that run tests in an
"at/" directory as another way to encourage the practice. (Module
authors who want su
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
David Golden wrote:
* Module::Starter -- Andy wants these tests run by default and he
doesn't seem to be swayed; So people need to fork this and start
advocating for an alternative. Ditto other module generators. (And
mea culpa for my own.)
You don't need to fork Module::Starter. You simpl
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
In fact, when a topic degrades to this level on the list go yell about it on
IRC. Email is the worst possible form of communication for this, its
optimized for big, detached speeches. At least IRC is more like a real time
conversation and the five people arguing won't scare off the hundred other
On Jul 31, 2007, at 4:08 PM, Eric Wilhelm wrote:
With the current situation[1], unaware users won't realize that
they are
shipping failing tests[2].
[1] Unless you add Test::Pod and Test::Pod::Coverage as prereqs to
Module::Starter.
Aha! Prereqs to Module::Starter ITSELF. Got it.
I had
Andy Lester wrote:
>
> On Jul 31, 2007, at 3:43 PM, David Golden wrote:
>
>> * Module::Starter -- Andy wants these tests run by default and he
>> doesn't seem to be swayed; So people need to fork this and start
>> advocating for an alternative.
>
> Or maybe it's just not that big a deal.
Once a
On Tue, Jul 31, 2007 at 04:43:08PM -0400, David Golden wrote:
> * CPANTS -- eliminating or penalizing Kwalitee for pod/pod-coverage
> tests would seem to be up to Thomas Klausner; I don't think I've seen
> him weigh in on this recently. So people need to lobby him or fork
> the project.
He's som
On Jul 31, 2007, at 3:43 PM, David Golden wrote:
* Module::Starter -- Andy wants these tests run by default and he
doesn't seem to be swayed; So people need to fork this and start
advocating for an alternative.
Or maybe it's just not that big a deal.
--
Andy Lester => [EMAIL PROTECTED] => ww
On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> This is not a functional failure; it has nothing to do with whether the *code*
> will behave correctly on a user's system.
That's not the question you posed. You asked why POD would "behave
differently". Ask a silly question, get a silly answer.
# from Andy Armstrong
# on Tuesday 31 July 2007 05:55 am:
>> This is the approach I thought of. I think you'll need to keep a
>> persistent file of output to capture require calls across each test
>> file and then summarize. (I.e. so you can set it as a command line
>> option to the harness.)
>
On Tuesday 31 July 2007 12:54:05 Christopher H. Laco wrote:
> > This is not a functional failure; it has nothing to do with whether the
> > *code* will behave correctly on a user's system.
> Unless that render failure also means that --help/pod2usage in a script
> doesn't work. Then it's a functi
chromatic wrote:
> On Tuesday 31 July 2007 12:35:06 David Golden wrote:
>
>> On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
>
>>> 1) POD can possibly behave any differently on my machine versus anyone
>>> else's machine, being non-executed text and not executed code
>
>> What version of Pod::S
On Tuesday 31 July 2007 12:35:06 David Golden wrote:
> On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> > 1) POD can possibly behave any differently on my machine versus anyone
> > else's machine, being non-executed text and not executed code
> What version of Pod::Simple do you have? What ve
On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> Please explain to me, in detail sufficient for a three year old, precisely
> how:
>
> 1) POD can possibly behave any differently on my machine versus anyone else's
> machine, being non-executed text and not executed code
What version of Pod::Simpl
# 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
Hi Ovid,
Ovid schrieb:
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
Can anyone think of anything wrong with the approach of replacing
require with an instrumented version? If the consensus is that that's
a sensible approach I'll play with tidying up the code.
You know, that solves an an
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
On Tuesday 31 July 2007 10:44:07 Salve J Nilsen wrote:
> In fact, this argument is ludicrus, and here's why:
>
> 1. We're playing the Open Source Development game here, of which the prime
> directive is "Many Eyes Make All Bugs Shallow". By denying end-users to
> partake in this game (by not givin
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. :)
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
Michael G Schwern wrote:
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 ou
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 13:39, David Golden wrote:
On 7/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
Can anyone think of anything wrong with the approach of replacing
require with an instrumented version? If the consensus is that that's
a sensible approach I'll play with tidying up the code.
Th
On 7/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Can anyone think of anything wrong with the approach of replacing
> require with an instrumented version? If the consensus is that that's
> a sensible approach I'll play with tidying up the code.
This is the approach I thought of. I think yo
On 7/31/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Slightly tangential but related: is there currently a module that
> simplifies simulating the non-availability of selected modules?
>
> use unavailable qw/LWP::UserAgent/;
> use Module::That::Needs::LWP::UserAgent;
>
>From the synopsis of De
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Can anyone think of anything wrong with the approach of replacing
> require with an instrumented version? If the consensus is that that's
> a sensible approach I'll play with tidying up the code.
You know, that solves an annoying problem I've ha
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:16, Ovid wrote:
I figure that running this on something like HTML::TokeParser::Simple
would be trivial. Running it on Jifty would be painful :)
Devel::TraceLoad seems to be on roughly the right track although it's
rather rough around the edges. It works by replacing
C
On 31 Jul 2007, at 12:24, Andy Armstrong wrote:
On 31 Jul 2007, at 12:16, Michael G Schwern wrote:
I was about to say that. I declare LWP as a prereq, but loading
LWP loads
tons more modules. I don't have to declare all those as prereqs,
in fact I
should not as its violating LWP's encaps
On 31 Jul 2007, at 12:34, Ovid wrote:
Can you just do the following?
BEGIN { $INC{'LWP/UserAgent.pm'} = 1 }
use Module::That::Needs::LWP::UserAgent;
Should be trivial to write, unless I have (as usual) missed glaringly
obvious corner cases.
That doesn't cause it to die immediately - be
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> use unavailable qw/LWP::UserAgent/;
> use Module::That::Needs::LWP::UserAgent;
>
Can you just do the following?
BEGIN { $INC{'LWP/UserAgent.pm'} = 1 }
use Module::That::Needs::LWP::UserAgent;
Should be trivial to write, unless I have (as u
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
On 31 Jul 2007, at 12:16, Michael G Schwern wrote:
I was about to say that. I declare LWP as a prereq, but loading
LWP loads
tons more modules. I don't have to declare all those as prereqs,
in fact I
should not as its violating LWP's encapsulation.
I don't know an easy way to give it the n
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
Adrian Howard wrote:
>
> On 31 Jul 2007, at 11:56, Ovid wrote:
> [snip]
>> We can see right away from the report above that Test::Class will cause
>> many folk's installs to fail since it's not listed as a prereq and it's
>> possible that SUPER doesn't need as high a version as is listed, though
>
--- Adrian Howard <[EMAIL PROTECTED]> wrote:
> Would the modules that get lists that are not your prerequisites, but
> are the prerequisites of the prerequisites of some of your
> prerequisites be problematical?
That's why this would just be a report and not a test. Manual
investigation woul
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> I like it. At some point in the future we could spew that information
> out as part of the TAP stream (as YAMLish metadata) and gather and
> analyse it in the harness.
Sounds great, but that we consume the test data, not produce it. The
reason
On 31 Jul 2007, at 11:56, Ovid wrote:
[snip]
We can see right away from the report above that Test::Class will
cause
many folk's installs to fail since it's not listed as a prereq and
it's
possible that SUPER doesn't need as high a version as is listed,
though
investigation into the histor
On 31 Jul 2007, at 11:56, Ovid wrote:
We can see right away from the report above that Test::Class will
cause
many folk's installs to fail since it's not listed as a prereq and
it's
possible that SUPER doesn't need as high a version as is listed,
though
investigation into the history for a
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. At the end
of the test run, it would load up the cached versions of %INC and build
a report of all loaded modules. Sample header:
M
54 matches
Mail list logo
