On Tuesday 12 September 2006 21:37, Michael G Schwern wrote:
> (For the sarcasm impaired, if you're just going to store the whole
> post-install source tarball you might as well just grab it from CPAN again)
I believe you meant to say BackPAN.
-- c
Adam Kennedy wrote:
> Frankly, I think anything you might write to try and pick and choose
> what to install is going to have problems.
>
> Since we're wasting... ermm... using all this extra disk space for tests
> anyway, why not just do the lot.
>
> Take the entire distribution post-make and ju
Adam Kennedy wrote:
But with that in mind, I still don't see much point in running them at
install-time, so lately I've modified my pod.t test so that it's skip
message is now "skipped: Author tests not required for installation" or
the like, and the tests now only run when AUTOMATED_TESTING is
On Sep 12, 2006, at 9:44 PM, Adam Kennedy wrote:
That's fine, but in my opinion, a slightly better solution for
author tests is to include them in revision control (i.e. SVN) but
to exclude them from the public distro via MANIFEST.SKIP. That's
what we do for the Perl::Critic self-complianc
The recent discussion(s) about quality goals and metrics got me to
thinking about what CPANTS is trying to do vs. what it's actually
doing. As a brainstorming exercise, I wrote down all of the software
quality goals I could think of quickly. For each existing CPANTS
metric, I decided whic
On Sep 12, 2006, at 8:20 PM, Adam Kennedy wrote:
Frankly, I think anything you might write to try and pick and
choose what to install is going to have problems.
Since we're wasting... ermm... using all this extra disk space for
tests anyway, why not just do the lot.
Take the entire distri
On Sep 12, 2006, at 6:54 PM, Adam Kennedy wrote:
[...]
That said, I've have come around a little on the subject of author
tests.
The one advantage they do have, is that their inclusion means that
while I may check POD structure, a pod.t ensures that in the event
of someone else taking ove
Frankly, I think anything you might write to try and pick and choose
what to install is going to have problems.
Since we're wasting... ermm... using all this extra disk space for tests
anyway, why not just do the lot.
Take the entire distribution post-make and just tarball that up and save
i
I think you've made an invalid assumption that examples will just happen
to have a console or input/output interface.
How do I show an example of using Wx.pm by implementing Windows Notepad
in the example. Or a POE asyncronous application, or a curses interface,
and so on.
Adam K
Gabor Szab
Gabor Szabo wrote:
On 9/13/06, Thomas Klausner <[EMAIL PROTECTED]> wrote:
In theory, we can now remove some of the very simple metrics (that
might not make that much sense), i.e. has_test_pod (no_pod_errors is
much better) and has_test_pod_coverage
The main reason why they're still here is beca
On Mon, 11 Sep 2006, David Golden wrote:
* test.pl vs t/*.t
* Custom Makefile.PL or Build.PL that affects test runs
* build_requires modules bundled in inc/
And don't forget that some tests may include tests data that is needed to
run the tests. If we're lucky, it's under t/
-dave
/*=
On 9/13/06, Thomas Klausner <[EMAIL PROTECTED]> wrote:
In theory, we can now remove some of the very simple metrics (that
might not make that much sense), i.e. has_test_pod (no_pod_errors is
much better) and has_test_pod_coverage
The main reason why they're still here is because I do get reports
Hi!
On Tue, Sep 12, 2006 at 11:15:50AM -0500, Chris Dolan wrote:
Wow, excellent post!
Some notes:
> The next step in the exercise becomes how to implement those
> measures. In the current CPANTS simple proxies are used for those
> measures. Namely, we assume that if there is a t/*pod.t fi
On Sep 12, 2006, at 9:24 AM, Salve J Nilsen wrote:
Any metric that catches bad things, particularly bad technical
things, is going to be just fine.
Metrics that try to push "good" behavior are fraught with trouble,
because they start pushing people in odd directions.
Do you have an example
Adam Kennedy wrote:
Of course some authors don't care about having a community around their
software, and some don't consider their CPAN package as "important" or
"big" enough to warrant a community (despite it probably being licensed
with an open source-friendly license). These people are en
Gabor Szabo wrote:
> Going along the path of testing the examples in my distribution,
> I think it could be generalized. What do you think about this?
I think putting the expected output into files fractures the test so that its
not obvious from just looking at the test what's going on. You have
- Original Message
From: Ken Williams
> Yes, I've been thinking about this for a long time. In fact, in the
> most recent M::B beta I made some steps toward it, by adding a
> 'retest' action that's just like 'test' except that it doesn't look
> in blib/, just in @INC. Functionally that
On Tue, Sep 12, 2006 at 12:36:49PM +0300, Gabor Szabo wrote:
> On 9/11/06, David Golden <[EMAIL PROTECTED]> wrote:
> >They probably need to be run in the same process. What about using
> >Test::Output or IO::Capture to capture the output (and keep it from
> >Test::Harness) and just running the cod
On 9/11/06, David Golden <[EMAIL PROTECTED]> wrote:
They probably need to be run in the same process. What about using
Test::Output or IO::Capture to capture the output (and keep it from
Test::Harness) and just running the code with "do code.pl"?
Thanks, this was a good idea though the main pr
19 matches
Mail list logo
