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 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
--- 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
--- 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
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. :)
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
# 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
17 matches
Mail list logo
