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
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:
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
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
--- 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 I
--- 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 would be
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
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
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
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
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
question
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
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?
--- Andy Armstrong [EMAIL PROTECTED] wrote:
use unavailable qw/LWP::UserAgent/;
use Module::That::Needs::LWP::UserAgent;
bang
Can you just do the following?
BEGIN { $INC{'LWP/UserAgent.pm'} = 1 }
use Module::That::Needs::LWP::UserAgent;
bang
Should be trivial to write, unless I have
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;
bang
Should be trivial to write, unless I have (as usual) missed glaringly
obvious corner cases.
That doesn't cause it to die immediately
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
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
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.2view=markup
As per my post of a few seconds ago, how about making it a pragma:
'unavailable'? :)
Does this
--- 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 had
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;
bang
From the synopsis of
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 you'll
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
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:
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
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
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
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. :)
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 giving them
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 which I've
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
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::Simple do you
# 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.)
Yup, I'm
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.
I
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] =
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
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 again,
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
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
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
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
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
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
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:
* 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
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.
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 silly.
Is it?
46 matches
Mail list logo
