Re: [Module::Build] Re: Test::META
On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote: On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends = ... testcover_requires = ... etc. This sounds useful and solves a lot of problems at one sweep. You can use the existing dependency architecture to determine what needs what. Such as testcover needs both test_requires and testcover_requires. There's a problem with this that I'm not sure how to solve: what happens when, as part of refactoring, a chunk of one action gets factored out to become its own sub-action? The dependency may well pertain to the new sub-action instead of the original action, but distribution authors won't have any way to know this - or even if they did, they couldn't declare it in a forward-compatible way. This is precisely the problem we're hitting with 'build_depends' vs. 'code_depends'. At one time, the 'build' action was a dependent of the 'test' action. So under our proposed dependency model, everything would work fine: before running the 'test' action, you run the 'build' action, which checks 'build_depends'. Then we perform refactoring, and we create a 'code' action that the 'build' and 'test' actions both can depend on. The distribution author still declares dependencies using 'build_depends', though - so when we run the 'test' action, we first run the 'code' action, which has no declared dependencies, and we end up with a nasty runtime error rather than a nice specific error about dependencies. Any solutions I'm missing? -Ken
Re: [Module::Build] Re: Test::META
On Mar 29, 2005, at 10:44 PM, Randy W. Sims wrote: Michael G Schwern wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed requirements. Or should we bail, for example, during ./Build test if there are any test_requires failures? Or continue as is and just let it fail when it tries to use the missing requirements? Continue. Nothing's more frustrating than a system which refuses to even try to go forward when some checklist is incomplete. Hmm, I was actually sitting here playing with it again. But I was leaning more towards the 2nd option. The first option of bailing at Build.PL time obviously doesn't make sense as you can complete a build without running test. But does it make sense to test when a required testing module is missing? Since the 'build', 'test', and 'install' actions are considered the critical path for installing a module, I think it makes sense to warn (not die) during perl Build.PL when one of their required/recommended/conflict dependencies aren't met. Thereafter, only die/warn when running an action and its required/recommended dependencies aren't met. -Ken
Re: [Module::Build] Re: Test::META
Ken Williams wrote: Since the 'build', 'test', and 'install' actions are considered the critical path for installing a module, I think it makes sense to warn (not die) during perl Build.PL when one of their required/recommended/conflict dependencies aren't met. Thereafter, only die/warn when running an action and its required/recommended dependencies aren't met. -Ken I'll show my lack of historical knowledge here, and this is swaying just a little off topic. If build, test, and install are considered the critical path, why was Build/make never changed to simple run test always as part of the builds success or failure? Just curious. In a way, I'd be much happier if 'perl Build' or 'make' outright failed if the tests didn't pass, just like if there was a c/linking error. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: [Module::Build] Re: Test::META
Ken Williams wrote: On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote: On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends = ... testcover_requires = ... etc. This sounds useful and solves a lot of problems at one sweep. You can use the existing dependency architecture to determine what needs what. Such as testcover needs both test_requires and testcover_requires. There's a problem with this that I'm not sure how to solve: what happens when, as part of refactoring, a chunk of one action gets factored out to become its own sub-action? The dependency may well pertain to the new sub-action instead of the original action, but distribution authors won't have any way to know this - or even if they did, they couldn't declare it in a forward-compatible way. I freely admit that I haven't been following this thread closely (I guess Ken's posts have a lower activation energy for me), but the suggested approach sounds way overengineered. How many modules really needs this kind of thing? I'm not sure that adding complexity to the requirements management system for those learning/using Module::Build is worth it for what I imagine to be relatively few modules that would wind up using such functionality. I'd rather see requires/recommends kept at a high level and let individual actions/tests check for what they need and be smart about how to handle missing dependencies. Regards, David
Re: [Module::Build] Re: Test::META
On Apr 1, 2005, at 2:55 PM, Christopher H. Laco wrote: If build, test, and install are considered the critical path, why was Build/make never changed to simple run test always as part of the builds success or failure? Just curious. In a way, I'd be much happier if 'perl Build' or 'make' outright failed if the tests didn't pass, just like if there was a c/linking error. Yeah, good question. I guess it's mostly historical. There's nothing really stopping us from creating an 'everything' action that does a 'build', 'test', and 'install' all in a row. Or maybe just the 'build' and 'test'. Anyone else like that idea? -Ken
Re: [Module::Build] Re: Test::META
Clayton, Nik wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed requirements. Or should we bail, for example, during ./Build test if there are any test_requires failures? Or continue as is and just let it fail when it tries to use the missing requirements? Continue. Nothing's more frustrating than a system which refuses to even try to go forward when some checklist is incomplete. Fail. Nothing's more frustrating than a system which fails with a strange error, when the real problem is listed somewhere in the scrollback buffer. Both. We could fail by default, but allow an option to force it to ignore missing or conflicting dependencies: $ perl Build test Aborting: Missing required module(s) for testing: Test::Foo Test::Bar $ perl Build test --force Ignoring: Missing required module(s) for testing: Test::Foo Test::Bar ... Just another option.
Re: [Module::Build] Re: Test::META
On Wed, Mar 30, 2005 at 06:12:37AM -0500, Randy W. Sims wrote: Both. We could fail by default, but allow an option to force it to ignore missing or conflicting dependencies: Duh. Why didn't I think of that? Of course!
Re: [Module::Build] Re: Test::META
Ken Williams wrote: On a related note, we should probably finally make the prerequisite-specification system treat the requirement level (requires vs. recommends vs. conflicts) and requirement scope (build vs. test vs. runtime) as completely orthogonal. Currently there's no such thing as build_recommends, for instance, but there's really no good reason it's missing. Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends = ... testcover_requires = ... etc. Also, this seems like a good time to implement .modulebuildrc (RT #8531). Except that I would rather follow the format of the rc files for tools like svn and cvs. If the word beginning the line matches the action being performed or the global '*', the options following it are appended to the current commandline. Perl-style comments. Backslash at the end of the line after comments are removed is line continuation. *--verbose # global options diff --flags -u install --install_base /home/randys \ --install_path html=/home/randys/html Objections? Comments? Randy.
Re: [Module::Build] Re: Test::META
On Mar 30, 2005, at 4:53 PM, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends = ... testcover_requires = ... etc. I like it. But for some reason I find it a little scary. Doing this would require a little bit of massaging for backward compatibility, because right now 'build_requires' contains prerequisites for the 'test' action, but 'build' doesn't run the 'test' action. Also, usually it's the 'code' action that *really* requires a prereq that would be mentioned in the 'build_requires' section, but I don't think we want people to start using 'code_requires' normally. Also, this seems like a good time to implement .modulebuildrc (RT #8531). Except that I would rather follow the format of the rc files for tools like svn and cvs. If the word beginning the line matches the action being performed or the global '*', the options following it are appended to the current commandline. Perl-style comments. Backslash at the end of the line after comments are removed is line continuation. *--verbose # global options diff --flags -u install --install_base /home/randys \ --install_path html=/home/randys/html Objections? Comments? I like it. -Ken
Re: [Module::Build] Re: Test::META
On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote: Should we completely open this up so that requires/recommends/conflicts can be applied to any action? install_recommends = ... testcover_requires = ... etc. This sounds useful and solves a lot of problems at one sweep. You can use the existing dependency architecture to determine what needs what. Such as testcover needs both test_requires and testcover_requires. From the automated build standpoint you'd need an API to simplify all this. Just tell me what's required and what's recommended Just tell me what I need to build, what I need to test and what I need to run Also, this seems like a good time to implement .modulebuildrc (RT #8531). Except that I would rather follow the format of the rc files for tools like svn and cvs. If the word beginning the line matches the action being performed or the global '*', the options following it are appended to the current commandline. Perl-style comments. Backslash at the end of the line after comments are removed is line continuation. *--verbose # global options diff --flags -u install --install_base /home/randys \ --install_path html=/home/randys/html Objections? Comments? My only comment is to lose the backslash. New commands are indicated by /^\S/
Re: [Module::Build] Re: Test::META
On Mar 28, 2005, at 6:21 PM, Randy W. Sims wrote: I think someone had proposed a year or two ago that there should be a test_requires options and I argued against it. Now, I think maybe it was a good idea; especially, since the number of extra testing modules being used have increased a lot over that time. I think there's one really good argument in favor of splitting it out and one really good argument against. In favor: if we knew the subset of build_requires that were actually needed for testing, then it would be easier for people to squirrel away the regression tests and run them again after the module is installed. I think people have been vaguely wanting that for a long time. Against: in the perl culture (largely because of the way MakeMaker has always been implemented), testing has always been seen as an integral part of the build process. By having people declare testing dependencies as part of build_requires, we reinforce this notion. On the whole, though, I think it's probably a good idea. On a related note, we should probably finally make the prerequisite-specification system treat the requirement level (requires vs. recommends vs. conflicts) and requirement scope (build vs. test vs. runtime) as completely orthogonal. Currently there's no such thing as build_recommends, for instance, but there's really no good reason it's missing. -Ken
Re: [Module::Build] Re: Test::META
On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote: I think there's one really good argument in favor of splitting it out and one really good argument against. In favor: if we knew the subset of build_requires that were actually needed for testing, then it would be easier for people to squirrel away the regression tests and run them again after the module is installed. I think people have been vaguely wanting that for a long time. Against: in the perl culture (largely because of the way MakeMaker has always been implemented), testing has always been seen as an integral part of the build process. By having people declare testing dependencies as part of build_requires, we reinforce this notion. On the whole, though, I think it's probably a good idea. To throw weight onto the in favor side. MB is a build tool. Tools should be flexible. Which choice results in the most flexible tool? Tools should also avoid trying to push their philosophy on others. It reduces flexibility and often chafes. Give the user the information and let them decide. Push your philosophy through the defaults, not by withholding information. On a related note, we should probably finally make the prerequisite-specification system treat the requirement level (requires vs. recommends vs. conflicts) and requirement scope (build vs. test vs. runtime) as completely orthogonal. Currently there's no such thing as build_recommends, for instance, but there's really no good reason it's missing. I'd agree here, too. If nothing else so that the user can decide if they really want that enormous optional module or if its just something that's going to allow one test to run.
Re: [Module::Build] Re: Test::META
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote:
I think there's one really good argument in favor of splitting it out
and one really good argument against.
In favor: if we knew the subset of build_requires that were actually
needed for testing, then it would be easier for people to squirrel away
the regression tests and run them again after the module is installed.
I think people have been vaguely wanting that for a long time.
Against: in the perl culture (largely because of the way MakeMaker has
always been implemented), testing has always been seen as an integral
part of the build process. By having people declare testing
dependencies as part of build_requires, we reinforce this notion.
On the whole, though, I think it's probably a good idea.
To throw weight onto the in favor side.
A quickie sample implementation to add more meat. I didn't apply yet
mainly because I'm wondering if we shouldn't bail and do a complete
roll-back (eg. don't generate a Build script) if there are any failed
requirements. Or should we bail, for example, during ./Build test if
there are any test_requires failures? Or continue as is and just let it
fail when it tries to use the missing requirements?
Randy.
Index: lib/Module/Build/Base.pm
===
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.400
diff -c -u -r1.400 Base.pm
--- lib/Module/Build/Base.pm24 Mar 2005 16:36:09 - 1.400
+++ lib/Module/Build/Base.pm30 Mar 2005 01:05:47 -
@@ -27,13 +27,13 @@
die Too early to specify a build action '$self-{action}'. Do 'Build
$self-{action}' instead.\n
if $self-{action};
- $self-_set_install_paths;
- $self-_find_nested_builds;
$self-dist_name;
+ $self-dist_version;
$self-check_manifest;
$self-check_prereq;
$self-set_autofeatures;
- $self-dist_version;
+ $self-_set_install_paths;
+ $self-_find_nested_builds;
return $self;
}
@@ -426,16 +426,12 @@
__PACKAGE__-add_property(build_script = 'Build');
__PACKAGE__-add_property(config_dir = '_build');
__PACKAGE__-add_property(blib = 'blib');
-__PACKAGE__-add_property(requires = {});
-__PACKAGE__-add_property(recommends = {});
-__PACKAGE__-add_property(build_requires = {});
-__PACKAGE__-add_property(conflicts = {});
__PACKAGE__-add_property('mb_version');
__PACKAGE__-add_property(build_elements = [qw(PL support pm xs pod script)]);
__PACKAGE__-add_property(installdirs = 'site');
__PACKAGE__-add_property(install_path = {});
__PACKAGE__-add_property(include_dirs = []);
-__PACKAGE__-add_property('config', {});
+__PACKAGE__-add_property(config = {});
__PACKAGE__-add_property(recurse_into = []);
__PACKAGE__-add_property(build_class = 'Module::Build');
__PACKAGE__-add_property(html_css = ($^O =~ /Win32/) ? 'Active.css' : '');
@@ -475,6 +471,23 @@
quiet
);
+{ # prerequisites
+ my @prereq_actions = ( 'Build.PL', 'build', 'test' );
+ my @prereq_types = qw( requires recommends conflicts );
+ __PACKAGE__-add_property(prereq_actions = [EMAIL PROTECTED]);
+ __PACKAGE__-add_property(prereq_types = [EMAIL PROTECTED]);
+ my @prereq_action_types;
+ foreach my $action ( @prereq_actions ) {
+foreach my $type ( @prereq_types ) {
+ my $req = $action eq 'Build.PL' ? '' : $action . '_';
+ $req .= $type;
+ __PACKAGE__-add_property( $req = {} );
+ push( @prereq_action_types, $req );
+}
+ }
+ __PACKAGE__-add_property(prereq_action_types = [EMAIL PROTECTED]);
+}
+
sub mb_parents {
# Code borrowed from Class::ISA.
my @in_stack = (shift);
@@ -657,7 +670,7 @@
File::Path::mkpath($self-{properties}{config_dir});
-d $self-{properties}{config_dir} or die Can't mkdir
$self-{properties}{config_dir}: $!;
- my @items = qw(requires build_requires conflicts recommends);
+ my @items = @{ $self-prereq_action_types };
$self-_write_dumper('prereqs', { map { $_, $self-$_() } @items });
$self-_write_dumper('build_params', [$self-{args}, $self-{config},
$self-{properties}]);
@@ -680,7 +693,7 @@
my $failures = $self-prereq_failures($info);
if ($failures) {
$self-log_warn(Feature '$name' disabled because of the following
prerequisite failures:\n);
- foreach my $type (qw(requires build_requires conflicts recommends)) {
+ foreach my $type ( @{$self-prereq_action_types} ) {
next unless $failures-{$type};
while (my ($module, $status) = each %{$failures-{$type}}) {
$self-log_warn( * $status-{message}\n);
@@ -697,7 +710,7 @@
sub prereq_failures {
my ($self, $info) = @_;
- my @types = qw(requires recommends build_requires conflicts);
+ my @types = @{ $self-prereq_action_types };
$info ||= {map {$_, $self-$_()} @types};
@@ -708,12 +721,12 @@
while ( my ($modname, $spec) = each %$prereqs ) {
my $status = $self-check_installed_status($modname, $spec);
- if
Re: [Module::Build] Re: Test::META
On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed requirements. Or should we bail, for example, during ./Build test if there are any test_requires failures? Or continue as is and just let it fail when it tries to use the missing requirements? Continue. Nothing's more frustrating than a system which refuses to even try to go forward when some checklist is incomplete.
Re: [Module::Build] Re: Test::META
Michael G Schwern wrote: On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote: A quickie sample implementation to add more meat. I didn't apply yet mainly because I'm wondering if we shouldn't bail and do a complete roll-back (eg. don't generate a Build script) if there are any failed requirements. Or should we bail, for example, during ./Build test if there are any test_requires failures? Or continue as is and just let it fail when it tries to use the missing requirements? Continue. Nothing's more frustrating than a system which refuses to even try to go forward when some checklist is incomplete. Hmm, I was actually sitting here playing with it again. But I was leaning more towards the 2nd option. The first option of bailing at Build.PL time obviously doesn't make sense as you can complete a build without running test. But does it make sense to test when a required testing module is missing? $ perl Build test Error: Missing required module(s) for testing: Test::Foo Test::Bar Well, I guess it could since you could still run some tests. But what about when building: $ perl Build build Error: Missing required module(s) for building: Build::Foo I would think if a module was required for building, then it will fail without that module. Or if not an error, should we at least spit it out as a warning? What about 'conflicts'? 'recommends' gets a mention at Build.PL time; I don't see any point in mentioning it again. Randy. Note: there is a problem in mainline with argument processing with no argument long options, eg `perl Build test --verbose` or equivalently `perl Build test verbose=1`. I haven't looked into it yet.
