module-build-general — General discussion about Module::Build project

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 2, 2006, at 12:11 PM, Tyler MacDonald wrote:

> 	If they're not a developer, what are they doing running unit tests
> in the first place??? End users typically install applications,  
> which either
> prebundle a whole bunch of perl packages or rely on some package  
> management
> system (ppm, deb, etc) to separate real dependancies from build  
> dependancies
> for them and only install what they need.

The end users may be in a different environment from me.  I usually  
only tests Perl 5.8.6 on OS X and Linux before release, so I rely on  
other installers to provide bug reports for me.

> 	I think in this case Test::Pod should be a build_requires... Your
> other examples (copyright.t, etc) obviously will only work on your  
> system so
> it makes sense for those to have some sort of special treatment.

Test::Pod is different from general regression tests.  POD should  
either pass on all systems or fail on all.  In what scenario would  
POD fail on a non-developer system.  And even if it did fail, do I  
want to scare people off from using my code because I have an =item  
without an =over?  No.  So, I want pod.t to be a non-core test in my  
modules.  Currently I only include it in MANIFEST because of Kwalitee 
[1].

Chris

[1] However, I am grateful to Kwalitee for getting to adopt Test::Pod  
and its ilk in the first place!

-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] version.pm and version number comparison problem

[John P. <jpe...@ro...>]

Julian Mehnle wrote:
> "This is wrong and you should not do it." -- What kind of justification is 
> that??

The POD has a little more than that (from UNIVERSAL::can):

> Some authors call methods in the UNIVERSAL class on potential
> invocants as functions, bypassing any possible overriding. This is
> wrong and you should not do it. Unfortunately, not everyone heeds
> this warning and their bad code can break your good code.

The use of UNIVERSAL::isa() and UNIVERSAL::can() as functions means that 
any class method by those names is rendered moot.  It means that you 
cannot use objects that only instantiate their true class when required 
(where you might want to have a custom isa() that effectively lies about 
what class(es) the object belongs to).

For example, imagine a polymorph class that takes on the characteristics 
of whatever class that is tested for (like Test::MockObject for 
example).  I suppose you could suggest that Module::Build load 
UNIVERSAL::isa (or at least Scalar::Util for the blessed() sub and call 
isa() as a object method instead).

> Why is it wrong to do UNIVERSAL::isa($foo, $type)?  This usage is 
> documented in `perldoc UNIVERSAL`, and it works fine, after all.

That POD was written a long time ago and should not be considered to be 
the only way to think about it.  As it turns out, UNIVERSAL::isa (the 
core code, not the CPAN replacement) was written in a poorly designed 
way that does not DTRT with some objects that are now in usage.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] version.pm and version number comparison problem

[Rob K. <rob...@gm...>]

On 2/2/06, Julian Mehnle <ju...@me...> wrote:
> Chris Dolan wrote:
> > On Feb 2, 2006, at 8:06 AM, John Peacock wrote:
> > >    # Unbless it if it's a version.pm object
> > > -  $result =3D "$result" if UNIVERSAL::isa( $result, 'version' );
> > > +  $result =3D $result->numify if UNIVERSAL::isa( $result, 'version' =
);
> >
> > While we're at it, we should change the
> >    UNIVERSAL::isa( $result, 'version' )
> > to
> >    eval { $result->isa('version') }
> >
> > See http://search.cpan.org/dist/UNIVERSAL-can/ for the
> > justification.  :-)
>
> "This is wrong and you should not do it." -- What kind of justification i=
s
> that??
>
> Why is it wrong to do UNIVERSAL::isa($foo, $type)?  This usage is
> documented in `perldoc UNIVERSAL`, and it works fine, after all.

What if I overload can() in order to correctly report what I support
through AUTOLOAD because I will handle dynamic attributes?
UNIVERSAL::can() fails there.

What if I overload isa() in order to report back a facade object is
really what it's decorating? UNIVERSAL::isa() fails there, too.

This isn't as unreasonable as it sounds. I overload isa() in
PDF::Template in order to use node names instead of class names
because the same class might handle multiple node types.

Rob

Re: [Module::Build] [RFC] author tests

[Eric W. <scr...@gm...>]

# from Tyler MacDonald
# on Thursday 02 February 2006 10:01 am:

>Whatever convention you're using, if these tests are only going to
>work on your system, then they definately shouldn't be in "t". 

There is a good case for that, particularly in reverse-compatibility.

> since there's absolutely no value in these types of tests for anybody
> else except the module author, 

Module hackers, if given the chance to run these tests (and encouraged 
to do so by the HACKING file), could potentially save the author a lot 
of trouble in accepting patches.

> there's no real point in having a 
> convention, just stick 'em anywhere that the make/buildfiles will
> ignore them.

No.  There is lots of real point in having a convention.  I would much 
rather that my tools be built and maintained by someone else.  If such 
conventions are not worthwhile, we should get rid of ./Build dist 
because each author might want to write that themselves.

I might be particular, but accepting someone else's convention (assuming 
that it works well enough) allows me to be lazy, which trumps 
particular by a factor of about 3 (might be pi.)

--Eric
-- 
Consumers want choice, consumers want openness.
--Rob Glaser
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [Module::Build] version.pm and version number comparison problem

[Julian M. <ju...@me...>]

Chris Dolan wrote:
> On Feb 2, 2006, at 8:06 AM, John Peacock wrote:
> >    # Unbless it if it's a version.pm object
> > -  $result =3D "$result" if UNIVERSAL::isa( $result, 'version' );
> > +  $result =3D $result->numify if UNIVERSAL::isa( $result, 'version' );
>
> While we're at it, we should change the
>    UNIVERSAL::isa( $result, 'version' )
> to
>    eval { $result->isa('version') }
>
> See http://search.cpan.org/dist/UNIVERSAL-can/ for the
> justification.  :-)

"This is wrong and you should not do it." -- What kind of justification is=
=20
that??

Why is it wrong to do UNIVERSAL::isa($foo, $type)?  This usage is=20
documented in `perldoc UNIVERSAL`, and it works fine, after all.

Re: [Module::Build] [RFC] author tests

[Tyler M. <ty...@yi...>]

Chris Dolan <ch...@cl...> wrote:
> This is NOT simpler, but is slightly more standardizable since the  
> first two lines could be identical for every author test.   
> Additionally, the first one implies to the user that their Perl  
> environment may be substandard without Test::Pod when really the lack  
> of Test::Pod is really a performance benefit to them if they're not a  
> developer!

	If they're not a developer, what are they doing running unit tests
in the first place??? End users typically install applications, which either
prebundle a whole bunch of perl packages or rely on some package management
system (ppm, deb, etc) to separate real dependancies from build dependancies
for them and only install what they need.

	I think in this case Test::Pod should be a build_requires... Your
other examples (copyright.t, etc) obviously will only work on your system so
it makes sense for those to have some sort of special treatment.

		- Tyler

Re: [Module::Build] [RFC] author tests

[Tyler M. <ty...@yi...>]

Chris Dolan <ch...@cl...> wrote:
>  * copyright.t - Ensures that there is a "Copyright ".([localtime]-> 
> [5]+1900) somewhere in every .pm file.  Will break 11 months from now.
>  * distribution.t - Relies on Test::Distribution, which is not in my  
> prereq list
>  * perlcritic.t - Runs Test::Perl::Critic on all .pm files.  Will  
> fail without my specific $HOME/.perlcriticrc and will fail with  
> future, more exhaustive versions of P::C
>  * spelling.t - Runs Test::Spelling.  Will fail without my custom  
> dictionary
>  * versionsync.t - Checks that the $VERSION is the same in all bin/*  
> and *.pm files.  This test is pointless after release, since it's  
> already been tested before release
>  * pod.t - Checks POD validity.  This test is pointless after  
> release, since it's already been tested before release
>  * pod-coverage.t - Checks POD completeness.  This test is pointless  
> after release, since it's already been tested before release
> 
> and one I have not yet employed:
>  * coverage.t - Ensures that Devel::Cover totals are higher than  
> some threshold

Wow, you really *are* exhaustive. How do you find the time to write any
code? ;-)

Now that I understand exactly what you mean by "author" tests, here's what I
think: Whatever convention you're using, if these tests are only going to
work on your system, then they definately shouldn't be in "t". And since
there's absolutely no value in these types of tests for anybody else except
the module author, there's no real point in having a convention, just stick
'em anywhere that the make/buildfiles will ignore them.

	- Tyler

Re: [Module::Build] [RFC] author tests

[Marvin H. <ma...@re...>]

On Feb 2, 2006, at 7:49 AM, Chris Dolan wrote:
> I'm specifically talking about author tests, NOT packager tests.

+1 on the idea of author tests.  I don't have strong opinions about  
the implementation.

For one of my distros, there's a script ./bin/test_valgrind.plx,  
which runs all the other tests under valgrind (this is an XS distro)  
and kicks out a log file for me to peruse.  Haven't quite figured out  
how to run it under Test::More, but that's how it ought to work, and  
it is clearly an author test, not a standard test, since it takes  
forever and depends upon the presence of valgrind.  There's also a ./ 
bin/test_tidiness.plx, which does a perltidy check on each .pm/.pod  
file -- which takes a while, depends upon perltidy, and is pointless  
after release for the same reason that checking pod is pointless  
after release.

If there had been a standardized procedure for me to follow, these  
scripts would be in a more sensible place than ./bin, and it would be  
more apparent what they're there for.  Also, if there had been a  
procedure for running all of them, they'd get run more reliably -- on  
the latest release I remembered to run the valgrind tests, but forgot  
the perltidy tests.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

Re: [Module::Build] version.pm and version number comparison problem

[Chris D. <ch...@cl...>]

On Feb 2, 2006, at 8:06 AM, John Peacock wrote:

>
>    # Unbless it if it's a version.pm object
> -  $result = "$result" if UNIVERSAL::isa( $result, 'version' );
> +  $result = $result->numify if UNIVERSAL::isa( $result, 'version' );

While we're at it, we should change the
   UNIVERSAL::isa( $result, 'version' )
to
   eval { $result->isa('version') }

See http://search.cpan.org/dist/UNIVERSAL-can/ for the  
justification.  :-)

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 2, 2006, at 10:02 AM, Rob Kinyon wrote:

> On 2/2/06, Chris Dolan <ch...@cl...> wrote:
>> On Feb 2, 2006, at 9:23 AM, Rob Kinyon wrote:
>>> This is, obviously, not quite compatible with EU::MM, but I don't
>>> think that's a problem.
>>
>> That last paragraph is the show-stopper.  If it doesn't work with
>> EU::MM then it's DOA.  This is why I initially proposed the *.ta
>> suffix, but now prefer the envvar trigger.  The envvar trigger is the
>> most backward- and cross-compatible suggestion to date, at the
>> expense of making the *.t files a tiny bit more complicated.
>
> It's not INcompatible with EU::MM ... just not completely compatible.
> If you use a MB-generated Makefile.PL (as I do), then MB would specify
> the test files by hand using the TESTS parameter to WriteMakefile(). I
> don't think there's an easy way to add to a new command to EU::MM, but
> if there was, then we could add the testfull command there, too.
>
> If you hand-generate your Makefile.PL, then it's your responsability
> to make sure that it's equivalent to the Build.PL, as it always has
> been.

Sorry, I wasn't clear enough about my objection.  Sure, anybody could  
make this work today with no enhancement to M::B or EU::MM.  But if  
it requires you to modify Makefile.PL or Build.PL in some special  
way, then it's just more cargo cult and no real community improvement.

Look at what happened to Tels recently with his custom YAML creating  
Makefile.PL on the perl-qa list.  He created a custom solution that  
mirrored the M::B META.yml solution, but when YAML.pm changed, he had  
to update *all* of his modules instead of just having his users  
update a single upstream package.  I see that as a process failure.

I started this thread to look for a consensus way to implement author  
tests in a more forward-looking way than the pod.t solution has been  
to date.

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 2, 2006, at 6:49 AM, David Golden wrote:

> Eric Wilhelm wrote:
>> I guess I'm undecided on this.  On the one hand, the *.ta  
>> convention is going to break the test juggler with which I've  
>> recently been experimenting, but on the other it means there is  
>> less 'whoami' code in the tests.  An example of my current whoami- 
>> based approach is below.
>
> My thought was that if someone wants to use *.ta files or a ta/*.t  
> directory, they can still do so by subclassing in Build.PL and  
> having a custom authortest action that includes those files.

Oh, sure, everything I've suggested in this thread *could* be done as  
Build.PL customization.  But the reason I brought this up was to try  
to achieve some consensus and find a Best Practice before the Cargo  
Cult started by Test::Pod takes a deeper hold.

I like the thought of having this as a feature in M::B because then  
it flattens the learning curve for a third party to mess with my  
author tests.  And as a corollary, I don't have to scratch my head as  
much when looking at someone else's author tests.

As a concrete example, take this standard pod.t:

   use Test::More;
   eval "use Test::Pod 1.14";
   plan skip_all => "Test::Pod 1.14 required for testing POD" if $@;
   all_pod_files_ok();

and rewrite as a hypothetical author test (I'm not advocating for  
"RUN_AUTHOR_TESTS" as a name):

   use Test::More;
   plan skip_all => "author test" if (!$ENV{RUN_AUTHOR_TESTS});
   eval 'use Test::Pod 1.14';
   all_pod_files_ok();

This is NOT simpler, but is slightly more standardizable since the  
first two lines could be identical for every author test.   
Additionally, the first one implies to the user that their Perl  
environment may be substandard without Test::Pod when really the lack  
of Test::Pod is really a performance benefit to them if they're not a  
developer!

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Rob K. <rob...@gm...>]

On 2/2/06, Chris Dolan <ch...@cl...> wrote:
> On Feb 2, 2006, at 9:23 AM, Rob Kinyon wrote:
> > This is, obviously, not quite compatible with EU::MM, but I don't
> > think that's a problem.
>
> That last paragraph is the show-stopper.  If it doesn't work with
> EU::MM then it's DOA.  This is why I initially proposed the *.ta
> suffix, but now prefer the envvar trigger.  The envvar trigger is the
> most backward- and cross-compatible suggestion to date, at the
> expense of making the *.t files a tiny bit more complicated.

It's not INcompatible with EU::MM ... just not completely compatible.
If you use a MB-generated Makefile.PL (as I do), then MB would specify
the test files by hand using the TESTS parameter to WriteMakefile(). I
don't think there's an easy way to add to a new command to EU::MM, but
if there was, then we could add the testfull command there, too.

If you hand-generate your Makefile.PL, then it's your responsability
to make sure that it's equivalent to the Build.PL, as it always has
been.

Rob

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 2, 2006, at 9:23 AM, Rob Kinyon wrote:

> What about doing the following:
> 1) Create a testfull action (vs. the normal test action - see
> testcover as precedence). This will run all the tests in test_files
> and fulltest_files
> 2) test_files is kept as t/*.t
> 3) fulltest_files is added as an option
>
> If you want to differentiate between regular tests and full tests,
> then you, as the author, are expected to use fulltest_files (and
> possibly test_files) to differentiate. Anything listed in
> fulltest_files (globs permitted) will be EXCLUDED from test_files.
>
> This is, obviously, not quite compatible with EU::MM, but I don't
> think that's a problem.

That last paragraph is the show-stopper.  If it doesn't work with  
EU::MM then it's DOA.  This is why I initially proposed the *.ta  
suffix, but now prefer the envvar trigger.  The envvar trigger is the  
most backward- and cross-compatible suggestion to date, at the  
expense of making the *.t files a tiny bit more complicated.

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote:

> Chris Dolan <ch...@cl...> wrote:
>> There is a class of tests that module authors perform that end users
>> are not expected to run.  For example code coverage tests, spelling
>> tests, coding style tests, etc.  These tests are either prohibitively
>> expensive or complicated or unpredictable for end users to run.  I
>> call these "private tests" or author tests.
>
> 	I really like this idea. But as you pointed out, it's not just
> authors that need to worry about running these tests, it's packagers
> (ppm/deb/etc), automated testers (cpants/testers.cpan.org/etc), and  
> hackers.
> I'd suggest we call these "exhaustive" tests.

No, I disagree.  I'm specifically talking about author tests, NOT  
packager tests.  Things like Test::Spelling are pointless and  
difficult for packagers to execute because Test::Spelling relies on  
an external aspell or ispell program *and* performs differently in  
the presence of an author's custom dictionary (mine has "Dolan"; does  
yours?)

These specifically are not exhaustive tests but spit-and-polish tests.

To make this less abstract, let me list the specific author tests  
that I employ for most of my CPAN modules, along with an explanation  
of why it wouldn't work for a packager

  * copyright.t - Ensures that there is a "Copyright ".([localtime]-> 
[5]+1900) somewhere in every .pm file.  Will break 11 months from now.
  * distribution.t - Relies on Test::Distribution, which is not in my  
prereq list
  * perlcritic.t - Runs Test::Perl::Critic on all .pm files.  Will  
fail without my specific $HOME/.perlcriticrc and will fail with  
future, more exhaustive versions of P::C
  * spelling.t - Runs Test::Spelling.  Will fail without my custom  
dictionary
  * versionsync.t - Checks that the $VERSION is the same in all bin/*  
and *.pm files.  This test is pointless after release, since it's  
already been tested before release
  * pod.t - Checks POD validity.  This test is pointless after  
release, since it's already been tested before release
  * pod-coverage.t - Checks POD completeness.  This test is pointless  
after release, since it's already been tested before release

and one I have not yet employed:
  * coverage.t - Ensures that Devel::Cover totals are higher than  
some threshold

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Rob K. <rob...@gm...>]

What about doing the following:
1) Create a testfull action (vs. the normal test action - see
testcover as precedence). This will run all the tests in test_files
and fulltest_files
2) test_files is kept as t/*.t
3) fulltest_files is added as an option

If you want to differentiate between regular tests and full tests,
then you, as the author, are expected to use fulltest_files (and
possibly test_files) to differentiate. Anything listed in
fulltest_files (globs permitted) will be EXCLUDED from test_files.

This is, obviously, not quite compatible with EU::MM, but I don't
think that's a problem.

Rob.

Re: [Module::Build] version.pm and version number comparison problem

[John P. <jpe...@ro...>]

Ron Savage wrote:
> and Text::RecordParser reports itself as being v1.0.0 (yes, with the goddam 'v',
> as if we needed it :-().

ENOTMYFAULT

Larry has spoken that version objects in Perl6 will be numbers with a leading
'v' (whether or not they are implemented in the same fashion as version.pm).

> 
> So, I see where the components of the error message (v1.0.0 and 0.02) come from.
> 
> My question is: Should this faulty comparison be something which is/can be
> handled properly by version.pm, meaning V 1.0.0 really is reported as being >
> V 0.02, or is this something we have to live with?

The problem is threefold:

1) Module::Build::ModuleInfo::_evaluate_version_line() currently uses version.pm
(if installed) to eval the $VERSION assignment, but then immediately throws away
the version object in preference to the *stringified* version;

2) Module::Build::Base::compare_versions() performs a trivial comparison (not
using the overloaded version comparison if available) of the two versions, which
will not work if the one version has a leading 'v' and multiple decimals;

3) The developers of Module::Build don't want to require version.pm to be
installed (because it requires XS code and I haven't been able to spend the time
to create a pure Perl implementation).

However, happily, I have a solution (diff vs. Module-Build-0.27_07):

--- lib/Module/Build/ModuleInfo.pm.orig 2006-02-02 08:46:21.000000000 -0500
+++ lib/Module/Build/ModuleInfo.pm      2006-02-02 08:59:23.000000000 -0500
@@ -299,7 +299,7 @@ sub _evaluate_version_line {
   warn "Error evaling version line '$eval' in $self->{filename}: $@\n" if $@;

   # Unbless it if it's a version.pm object
-  $result = "$result" if UNIVERSAL::isa( $result, 'version' );
+  $result = $result->numify if UNIVERSAL::isa( $result, 'version' );

   return $result;
 }

This will render the version object into the equivalent numeric form, which
*will* compare trivially with non-version objects.  All M::B tests pass and more
importantly for you, SQL::Translator now accepts the installed version of
Text::RecordParser.

HTH

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: [Module::Build] [RFC] author tests

[David G. <da...@hy...>]

Eric Wilhelm wrote:
> I guess I'm undecided on this.  On the one hand, the *.ta convention is 
> going to break the test juggler with which I've recently been 
> experimenting, but on the other it means there is less 'whoami' code in 
> the tests.  An example of my current whoami-based approach is below.

My thought was that if someone wants to use *.ta files or a ta/*.t 
directory, they can still do so by subclassing in Build.PL and having a 
custom authortest action that includes those files.

David

Re: [Module::Build] version.pm and version number comparison problem

[<and...@fr...>]

>>>>> On Thu, 02 Feb 2006 15:06:28 +1100, Ron Savage <ro...@sa...> said:

  > Hi Folks
  > Just wondering:

  > I'm using version V 0.53 and Module::Build V 0.2611.

  > When I try to install SQL::Translator (for example) I get:

  > Checking whether your kit is complete...
  > Looks good
  >  * Version v1.0.0 of Text::RecordParser is installed, but we prefer to have 0.02
  > ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions
  >  of the modules indicated above before proceeding with this installation.

  > The Build.PL for SQL::Translator says:

  >     recommends        => {
  >         'GD'                      => 0,
  >         'GraphViz'                => 0,
  >         'IO::File'                => 0,
  >         'IO::Scalar'              => 0,
  >         'Spreadsheet::ParseExcel' => 0.2602,
  >         'Text::ParseWords'        => 0,
  >         'Text::RecordParser'      => 0.02,
  >         'XML::Writer'             => 0.500,
  >         'XML::XPath'              => 1.13,
  >         'YAML'                    => 0.39,
  >     },

  > and Text::RecordParser reports itself as being v1.0.0 (yes, with the goddam 'v',
  > as if we needed it :-().

Nono, the relevant line in Text::RecordParser is

  our $VERSION = version->new('1.0.0');

So do not blame the v, it is just version.pm that helps us a little
with overloading.

  > So, I see where the components of the error message (v1.0.0 and 0.02) come from.

  > My question is: Should this faulty comparison be something which is/can be
  > handled properly by version.pm, meaning V 1.0.0 really is reported as being >
  > V 0.02, or is this something we have to live with?

I suppose this is a bug in Module::Build, because version.pm can
compare 1.0.0 and 0.02 as you would expect:

% perl -le '
use version 0.53;
print version->new("1.0.0") > 0.02 ? "ok" : "not ok";         
'
ok


-- 
andreas

Re: Fwd: [Module::Build] Does ./Build work on Windows?

[demerphq <dem...@gm...>]

On 2/2/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> >
> > The change required to MB to handle this is minimal and is implemented
> > in a provisional form in the attached patch.
> >
> > When the Build script is created it needs to add the line
> >
> >   close *DATA unless eof(*DATA);
> >
> > when being used on win32.
>
> I think we can simplify, and apply this to all platforms.

I think that this can be avoided for anything but clean like targets,
and for those targets it occured to me that it probably should happen
as late as possibe. I'm not sure if i read your patch correctly, maybe
it already does that but it thought it would be worth mentioning.

>  > Then the exception line in pl2script needs
> > to be removed.
>
> > Additionally when scripts are pl2bat'ed their bat names need to be
> > added to the cleanup list. This currently doesnt happen at all so MB
> > cant/doesnt clean up pl2batted files properly. (It may do so
> > indirectly as a directory cleanup but this doesnt help the build
> > script itself.)
>
> Yeah. They were cleaned up as part of blib, but you're right, it should
> be mentioned explicitly here.

Ok. Im glad i didnt miss it happening somewhere/somehow else. :-)

> > Also, my preference (and i think the preference of many in the windows
> > world) is to avoid ".bat" files on NT and latter Win32 OS'es. It
> > should use the .cmd extension when on NT, W2K and XP or later.  I
> > hazzily recall there is a good reason for this, but i have to admit I
> > dont remember what it is. Maybe its just cargo cultism and doesnt
> > matter at all. Anyway, the point is the attached patch includes such
> > logic. :-) I based it the behaviour change on the presence of .CMD in
> > the PATHEXT enviornment var so on machines without either it will
> > default to .bat
>
> Ok.

Sigh. I'm now wondering about the wisdom of this. Other tools may be
expecting '.bat' extensions and fail because of the change. I think
actually despite my other feelings on it that a more conservative
approach is called for and this change should be reversed until we can
find proof that there is a good reason for it (my hazy recollections
dont count).  Maybe it could be made optional somehow. But ill leave
that decision to you.

Sorry to waste your time with it.

> > Im sorry i havent gotten further on this, i was distracted by other thi=
ngs.
>
> No problem. You're work on this and on fixing the "Cwd won't install"
> problem in EU::Install is very very much appreciated.
>
> > BTW, there is one annoying thing about self deletion of the .cmd/.bat
> > Build file. When control returns to the shell it raises a warning
> > about the batch file unexpected ending. Its not an issue, but it is
> > inelegant so figuring out how to make it go away would be nice.
>
> This is the only issue holding me up. I'm going to do some experimenting
> and research to see if that annoying message can be eliminated somehow.

Yeah. Its an interesting question. Ill look into it too.

> Attached is a manually applied version of your patch against current
> cvs. The only changes are applying the close(*DATA) on all OS, removing
> the extraneous Build_FollowUp logic, and some line wraps.

Ill have a go applying it later. Thanks.
yves

> Index: lib/Module/Build/Base.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
> retrieving revision 1.544
> diff -u -r1.544 Base.pm
> --- lib/Module/Build/Base.pm    23 Jan 2006 13:27:43 -0000      1.544
> +++ lib/Module/Build/Base.pm    2 Feb 2006 00:54:22 -0000
> @@ -1188,6 +1188,9 @@
>  use File::Basename;
>  use File::Spec;
>
> +close(*DATA) unless eof(*DATA);  # must close before unlinking ourself
> +                                 #  necessary on MSWin32 for realclean a=
ction
> +
>  sub magic_number_matches {
>    return 0 unless -e '$q{magic_numfile}';
>    local *FH;
> @@ -1257,6 +1260,7 @@
>    $self->print_build_script($fh);
>    close $fh;
>
> +  local $self->{properties}{quiet} =3D 1;
>    $self->make_executable($build_script);
>
>    return 1;
> Index: lib/Module/Build/Platform/Windows.pm
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Platform/Wi=
ndows.pm,v
> retrieving revision 1.26
> diff -u -r1.26 Windows.pm
> --- lib/Module/Build/Platform/Windows.pm        21 Jan 2006 18:05:01 -000=
0      1.26
> +++ lib/Module/Build/Platform/Windows.pm        2 Feb 2006 00:54:22 -0000
> @@ -56,16 +56,20 @@
>    my $pl2bat =3D $self->{config}{pl2bat};
>
>    if ( defined($pl2bat) && length($pl2bat) ) {
> -    foreach my $script (@_) {
> -      # Don't run 'pl2bat.bat' for the 'Build' script;
> -      # there is no easy way to get the resulting 'Build.bat'
> -      # to delete itself when doing a 'Build realclean'.
> -      next if ( $script eq $self->{properties}{build_script} );
> +    my $ext =3D ( $ENV{PATHEXT}=3D~/\.CMD(\W|$)/i )
> +                ? '.cmd' : '.bat';
>
> +    foreach my $script (@_) {
>        (my $script_bat =3D $script) =3D~ s/\.plx?//i;
> -      $script_bat .=3D '.bat' unless $script_bat =3D~ /\.bat$/i;
>
> -      my $status =3D $self->do_system("$self->{properties}{perl} $pl2bat=
 < $script > $script_bat");
> +      # already has executable extension
> +      next if ($script_bat =3D~ /\.(bat|cmd)$/i);
> +
> +      $script_bat .=3D $ext;
> +      $self->add_to_cleanup($script_bat);
> +
> +      my $status =3D $self->do_system(
> +        "$self->{properties}{perl} $pl2bat < $script > $script_bat" );
>        if ( $status && -f $script_bat ) {
>          $self->SUPER::make_executable($script_bat);
>        } else {
>
>
>


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

[Module::Build] version.pm and version number comparison problem

[Ron S. <ro...@sa...>]

Hi Folks

Just wondering:

I'm using version V 0.53 and Module::Build V 0.2611.

When I try to install SQL::Translator (for example) I get:

Checking whether your kit is complete...
Looks good
 * Version v1.0.0 of Text::RecordParser is installed, but we prefer to have 0.02
ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions
 of the modules indicated above before proceeding with this installation.

The Build.PL for SQL::Translator says:

    recommends        => {
        'GD'                      => 0,
        'GraphViz'                => 0,
        'IO::File'                => 0,
        'IO::Scalar'              => 0,
        'Spreadsheet::ParseExcel' => 0.2602,
        'Text::ParseWords'        => 0,
        'Text::RecordParser'      => 0.02,
        'XML::Writer'             => 0.500,
        'XML::XPath'              => 1.13,
        'YAML'                    => 0.39,
    },

and Text::RecordParser reports itself as being v1.0.0 (yes, with the goddam 'v',
as if we needed it :-().

So, I see where the components of the error message (v1.0.0 and 0.02) come from.

My question is: Should this faulty comparison be something which is/can be
handled properly by version.pm, meaning V 1.0.0 really is reported as being >
V 0.02, or is this something we have to live with?
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Module::Build] [RFC] author tests

[Ron S. <ro...@sa...>]

On Wed, 01 Feb 2006 23:28:40 -0500, David Golden wrote:

Hi David

> Chris Dolan wrote:
>> I am not wed to the t/*.ta convention or the name of the ACTION.
>>  What do others think of the concept in general?

What if such tests were in ta/*.t, thus keeping them out of the way of end
users?

--
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Module::Build] [RFC] author tests

[Eric W. <scr...@gm...>]

# from David Golden
# on Wednesday 01 February 2006 08:28 pm:

>Chris Dolan wrote:
>> I am not wed to the t/*.ta convention or the name of the ACTION. =A0
>> What do others think of the concept in general?
>
>What if "authortest" instead set an environment variable prior to
>running the normal "test" action?

I guess I'm undecided on this.  On the one hand, the *.ta convention is=20
going to break the test juggler with which I've recently been=20
experimenting, but on the other it means there is less 'whoami' code in=20
the tests.  An example of my current whoami-based approach is below.

I suppose it would be nice for it to work both with a *.ta typeglob and=20
to set an environment variable.  Possibly the environment variable(s)=20
used should be configurable in Build.PL?  e.g. it might be handy to=20
have the following sort of control:

  # runs all of the *.t* files with all authortest_env =3D> [qw(POD WARN)]
  ./Build authortest
  # just set AUTHORTEST_POD and run all *.t*
  ./Build authortest POD
  # just set AUTHORTEST_WARN and run all *.t*
  ./Build authortest WARN

But then you might also want Build.PL to configure whether or not *.t=20
tests are run?

=2D------
  #!/usr/bin/perl

  use Test::More;
  eval "use Test::Pod::Coverage 1.04";
  plan skip_all =3D>
    "Test::Pod::Coverage 1.04 required for testing POD coverage"
	if $@;
  plan skip_all =3D> '$ENV{TEST_POD_COVERAGE} is not set'
    unless((($ENV{USER} || '') eq 'ewilhelm') or   =20
      exists($ENV{TEST_POD_COVERAGE}));
  all_pod_coverage_ok();
=2D------

=2D-Eric
=2D-=20
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
=2D-Robert G. Brown
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [Module::Build] [RFC] author tests

[Chris D. <ch...@cl...>]

On Feb 1, 2006, at 10:28 PM, David Golden wrote:

> Chris Dolan wrote:
>> I am not wed to the t/*.ta convention or the name of the ACTION.    
>> What do others think of the concept in general?
>
> What if "authortest" instead set an environment variable prior to  
> running the normal "test" action?  (Look at "testcover" as an  
> example of  this.)
>
> Then .t files could take various actions based on the presence of  
> that environment variable.  At the most basic -- just skip_all.   
> However, this would also allow perhaps more diagnostic information  
> to be provided for the author if desired.
>
> My point is that making it *.ta specific allows only one way of  
> doing author testing.  The environment variable way just signals  
> that author testing is being requested and lets the existing test  
> scripts choose how to respond.

That's pretty smart.  It certainly requires less coordination, and  
would work fine with normal EU::MM setups (just manually set the  
envvar).

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] [RFC] author tests

[Tyler M. <ty...@yi...>]

Chris Dolan <ch...@cl...> wrote:
> There is a class of tests that module authors perform that end users  
> are not expected to run.  For example code coverage tests, spelling  
> tests, coding style tests, etc.  These tests are either prohibitively  
> expensive or complicated or unpredictable for end users to run.  I  
> call these "private tests" or author tests.

	I really like this idea. But as you pointed out, it's not just
authors that need to worry about running these tests, it's packagers
(ppm/deb/etc), automated testers (cpants/testers.cpan.org/etc), and hackers.
I'd suggest we call these "exhaustive" tests.

	Spelling tests, code coverage tests, testing interaction with
CPAN.pm, etc. are things that I think should be done by automated testers,
and by people packaging your module for distribution inside another larger
system (eg, PPMs or debian packages). So maybe it would make sense if there
were certain tests that only run if AUTOMATED_TESTING is set, and/or if the
"disttest" action is being run.

	That said, it would be easy to whip together a Test:: module that
only allows these tests to run under these conditions, especially if
Module::Build, say, set a "DIST_TEST" environment variable when the disttest
action was being run. I already check for AUTOMATED_TESTING to manipulate my
test environments to be more exhaustive. Both Module::Build, and perhaps
future versions of ExtUtils::MakeMaker (if there will ever be a future
version) could depend on this Test:: module (whether or not they use it
themselves) so that it's already on everybody's system. It'd be nice and
small so I don't see anybody complaining too loudly.

	Maybe we could call it "Test::Exhaustive"? It's mandate being to
SKIP_ALL of a test if you havent somehow (AUTOMATED_TESTING, disttest, etc)
made it clear that you wish to exhaustively test this module?

> Roughly, I propose that we adopt a standard file extension for author  
> tests, like "t/*.ta", and add an ACTION_authortest to M::B that runs  
> both t/*.t and t/*.ta (which ones first??)

	If they were named differently (i don't think they have to be), I'd
want to see them run in lexical order like the current tests, so it'd go
"01foo.t", "02bar.ta", "03baz.t".

	Cheers,
		Tyler

Re: [Module::Build] [RFC] author tests

[David G. <da...@hy...>]

Chris Dolan wrote:
> I am not wed to the t/*.ta convention or the name of the ACTION.   What 
> do others think of the concept in general?

What if "authortest" instead set an environment variable prior to 
running the normal "test" action?  (Look at "testcover" as an example of 
  this.)

Then .t files could take various actions based on the presence of that 
environment variable.  At the most basic -- just skip_all.  However, 
this would also allow perhaps more diagnostic information to be provided 
for the author if desired.

My point is that making it *.ta specific allows only one way of doing 
author testing.  The environment variable way just signals that author 
testing is being requested and lets the existing test scripts choose how 
to respond.

Regards,
David