module-build-general

[Module::Build] META.yml feature for autotesters?

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

	I've been thinking about automated testing again. I know this is a
bad habit and I should stop it and just get on with my work, but here's
where I'm at:

	Sometimes it's beneficial for an automated tester to install
additional packages (in software I'm releasing, Test::CPANpm and sqlite are
perfect examples). It would be good to have a standard way to tell a smoke
tester what these packages are.

	How does everybody feel about making this a defined "feature" in
the META.yml spec? Something like:

optional_features:
  - automated_testing:
      description: Automated testing of all of this package's features
      requires:
        DBD::SQLite2: 0

	If an optional_feature field for packages useful for automated
testing was standardized, functionality could be added to CPAN::YACSmoke and
PITA to take advantage of it, and then there would be an easy way for an
author to define prerequisites for doing an exhaustive smoke test of their
distribution.

	What do y'all think?

	Thanks,
		Tyler

[Module::Build] Re: META.yml feature for autotesters?

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

[NOTE: I trimmed the CC list to just module-build-general, since my  
answer reflects only that system]

On Feb 24, 2006, at 2:51 PM, Tyler MacDonald wrote:

> 	I've been thinking about automated testing again. I know this is a
> bad habit and I should stop it and just get on with my work, but  
> here's
> where I'm at:
>
> 	Sometimes it's beneficial for an automated tester to install
> additional packages (in software I'm releasing, Test::CPANpm and  
> sqlite are
> perfect examples). It would be good to have a standard way to tell  
> a smoke
> tester what these packages are.
>
> 	How does everybody feel about making this a defined "feature" in
> the META.yml spec? Something like:
>
> optional_features:
>   - automated_testing:
>       description: Automated testing of all of this package's features
>       requires:
>         DBD::SQLite2: 0
>
> 	If an optional_feature field for packages useful for automated
> testing was standardized, functionality could be added to  
> CPAN::YACSmoke and
> PITA to take advantage of it, and then there would be an easy way  
> for an
> author to define prerequisites for doing an exhaustive smoke test  
> of their
> distribution.
>
> 	What do y'all think?

M::B briefly included a 'build_recommends' property that did about  
what you propose.  The idea was that people would put  
Test::Pod::Coverage and the like in that field.  It was removed in  
0.27_04 in favor of the more customizable prereq_action_types()  
feature.  That feature avoids the overwhelming combinatorics of  
{,build_,test_,install_}{requires,recommends,conflicts} etc. most of  
which were rarely used.

Here's the explanation from the Changelog:

    0.27_04  Fri Dec 23 10:43:34 CST 2005
     - Removed experimental feature that extended the prerequisite  
system
       to apply ('requires', 'recommends', and 'conflicts') prereqs  
to all
       actions. Most of the internal extensiblity has been retained so
       that prereq types can easily be added, more selectively.

The prereq_action_types feature seems to be undocumented, so I'll  
leave it to someone more experienced to explain the right way to add  
a build_recommends...

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/)

[Module::Build] Re: META.yml feature for autotesters?

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

Chris Dolan <ch...@cl...> wrote:
> The prereq_action_types feature seems to be undocumented, so I'll  
> leave it to someone more experienced to explain the right way to add  
> a build_recommends...

	Sounds interesting, I'll have to look into that a bit more. From a
quick glance it looks like prereq_action_types is only used a few times in
the source. The "blead" META.yml spec doesn't say anything about
build_recommends... Ken, is build_recommends currently the desired way for a
META.yml to tell testers what packages they should install to do the most
complete test pass possible?

	Cheers,
		Tyler

[Module::Build] Re: META.yml feature for autotesters?

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

Adam Kennedy <cp...@al...> wrote:
> So while we are on the subject of META.yml, I think the dynamic_config 
> approach is horrible, because it defaults to an efficient error case and 
> relies on the author to fix the error, rather than defaulting to the 
> inefficient correct case, and giving the option to make it faster.
> 
> Where would be the best place to get this flag changed (or for a 
> discussion on doing so) in the spec?

	The module-build project, maintained by Ken Williams, is currently
hosting the META.yml spec;

	http://module-build.sourceforge.net/

	I guess META.yml's "reccomends" feature accomplishes most of what
I'm after (if you can't install the module don't worry about it, but if you
can, it'll enhance things), but what I was looking for was a place to dump
stuff like that that doesn't affect the usability of the package, just the
testability. "build_recommends" was suggested on module-build-general, but
it appears to have disappeared from the Module::Build code and isn't on the
META.yml spec.

		- Tyler