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
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 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. Especially if the work done to get to that point takes time. I'd much rather # make all test Missing dependency: Test::Foo than # make all test Building ... go get coffee, perhaps some of the tests that do run are quite time consuming, or the build process has a long compilation step ... some failure message ... N
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: Test::META
On Mon, Mar 28, 2005 at 08:35:34PM -0800, Michael G Schwern wrote: Whether things that are required for *testing* belong in build_requires really depends on whether you view testing as an integral part of the build process. This is something that is likely to depend on the *builder*, not the module author, which is, in my mind, the only argument (and a good one) for a separate test_requires. The distinction between build_recommends and and a possible test_recommends is more ambiguous. I agree with this, however I don't really see the ambiguity about test_recommends. ambiguous was the wrong word to use, sorry. I just meant that the argument for separating out test_requires is a lot stronger than for test_recommends; I'd like to see them both, but I had the impression public opinion was weighted against them, so I was trying to argue for the more important one.
Re: Test::META
Michael G Schwern wrote: [snip] Sticking with ExtUtils::MakeMaker. :-) [But where's the fun in that.] I know you're joking, but you've flipped my rant switch. I was. But at some level, I'm not. If after changing one dist to use M::B I have more issues than I started with [which was just checking the syntax of my manually edited META.yml], then there's no reason to move all of my dists; even if there are only 6 of them. However, the same could be said about my META.yml files period. They weren't broken; just incompleted. I'm the type of idiot that gets the urge to put everything pertinent I can into my META.yml files, even if E::M and M::B don't currently have the means to do exactly what I want. [snip] But it hasn't. And I only see a small number of people patching Module::Build. And there's tons of low hanging fruit available. What's going on here? One thing I see going on is that people are holding Module::Build up to rediculously high standards. Much, much higher than MakeMaker ever was. Anything Module::Build tries to do people still nit-pick it to death, and here's the horrible part, they don't generate much patches. I would think the same is true of any 'replacement' dist. I wonder if CPAN/CPANPLUS don't suffer from the same issue. Take dependency resolution. MakeMaker has one way to specify a dependency. MB has a whole spectrum. And yet people still want to fall back to MM's low resolution dep system because MB's isn't quite high enough. Take create_makefile_pl. Module::Build bends over backwards to be compatible with MakeMaker. It offers not one but THREE different methods of providing that. Hell, it'll even generate a Makefile.PL that will download MB for you! And yet when people encounter small problems with it the response isn't Here's a patch or even I'll just work around that for now. No, its I'm going back to MakeMaker where they'll likely have to do more work and more work arounds to achieve the same effect. Guilty as charged. See top comments. It's not 'going back', it's 'sticking with what already is in place'. I'd be all to willing to take a stab at patching test_requires and the ability to choose whether create_makefile_pl adds recommends: to PREREQ_PM or not during create_makefile_pl. But the former meant getting the META.yml spec updated as well, which didn't seam like something that would happen anytime soon. Maybe that's a bad assumption. [snip] The point is this. * Give MB a chance. * When you encounter a problem in MB, try to patch it. * Do not expect Ken and Randy to do all the work for you. * Do not immediately run back to the warm, familiar, utterly flawed embrace of MakeMaker. Thank you. This has been a rant. So back to M::B I shall go, and I'll make it do my bidding come hell or high patch water. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Module::Build] Re: Test::META
On Mar 28, 2005, at 4: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 it's a good idea, although since most Perl module users run `make test` as part of the build process, I've been comfortable just putting such requirements into build_requires. But the distinction *is* significant, IME. Regards, David
Re: Test::META
On Tue, Mar 29, 2005 at 09:04:54AM -0500, Christopher H. Laco wrote: I was. But at some level, I'm not. If after changing one dist to use M::B I have more issues than I started with [which was just checking the syntax of my manually edited META.yml], then there's no reason to move all of my dists; even if there are only 6 of them. However, the same could be said about my META.yml files period. They weren't broken; just incompleted. I'm the type of idiot that gets the urge to put everything pertinent I can into my META.yml files, even if E::M and M::B don't currently have the means to do exactly what I want. See, this is what I don't understand. You have an issue about the details of the way MB generates META.yml, but MM barely generates it at all! And if you're manually editing it... why is the generation even an issue? And you're worried about how create_makefile_pl translates recommends... MakeMaker doesn't even have a recommend! I can't see how the conclusion is I'm going back to MM. I could see how the conclusion might be I'm not using recommends anymore. What's going on here? One thing I see going on is that people are holding Module::Build up to rediculously high standards. Much, much higher than MakeMaker ever was. Anything Module::Build tries to do people still nit-pick it to death, and here's the horrible part, they don't generate much patches. I would think the same is true of any 'replacement' dist. I wonder if CPAN/CPANPLUS don't suffer from the same issue. It doesn't seem to, but there was much less voodoo surrounding CPAN.pm. Also less inertia. There's less to learn going CPAN - CPANPLUS. Some slightly different shell commands. Then again, I'm not sitting in the middle of the CPANPLUS world. I'm sure Jos might have choice things to say. I'd be all to willing to take a stab at patching test_requires and the ability to choose whether create_makefile_pl adds recommends: to PREREQ_PM or not during create_makefile_pl. Here's a compromise. Instead of adding options to create_makefile_pl, find a better default behavior. What do Makefile.PL authors do right now when they have a recommended module? They ask the user. Its not really the author's choice, its the user's. Have MB::Compat add a bit of code to the Makefile.PL which uses prompt() to ask the user for each recommended module if they want it installed. If they do, throw it into PREREQ_PM. If they don't, don't. But the former meant getting the META.yml spec updated as well, which didn't seam like something that would happen anytime soon. Maybe that's a bad assumption. It feels like they're ready for it. Anyhow, its simpler to just patch the code and then let the spec follow. :) So back to M::B I shall go, and I'll make it do my bidding come hell or high patch water. Thank you.
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.
Re: Test::META
Michael G Schwern [EMAIL PROTECTED] writes: Switch to Module::Build anyway. I would love to. But the last time I submitted a M::B-only module I was 'kindly urged' to provide a Makefile.PL as well, factually defeating the advantages of using M::B. Maintaining both a Build.PL and a Makefile.PL is not fun, except in easy cases. (Will try to switch to M::B anyway...) -- Johan
Re: Test::META
On Mon, Mar 28, 2005 at 01:04:45PM +0200, Johan Vromans wrote: Michael G Schwern [EMAIL PROTECTED] writes: Switch to Module::Build anyway. I would love to. But the last time I submitted a M::B-only module I was 'kindly urged' to provide a Makefile.PL as well, factually defeating the advantages of using M::B. Ya know, you don't have to do everything everyone says. ;) Maintaining both a Build.PL and a Makefile.PL is not fun, except in easy cases. I see the work you did in Template::TT2Site for this. Its, for the most part, not necessary. There is a create_makefile_pl option (see Module::Build::Compat) which does a fair job of creating a Makefile.PL functionally equivalent to your Build.PL. It comes in various flavors from passthrough (where it writes a Makefile which simply calls Module::Build functions) to a pure MakeMaker implementation. Flipping through the Makefile.PLs of your modules they look for the most part trivial and would be handled fine by create_makefile_pl.
Re: Test::META
Michael G Schwern [EMAIL PROTECTED] writes: There is a create_makefile_pl option (see Module::Build::Compat) which does a fair job of creating a Makefile.PL functionally equivalent to your Build.PL. I'll definitely give it a try. Thanks. -- Johan
Re: Test::META
Michael G Schwern wrote: There is a create_makefile_pl option (see Module::Build::Compat) which does a fair job of creating a Makefile.PL functionally equivalent to your Build.PL. It comes in various flavors from passthrough (where it writes a Makefile which simply calls Module::Build functions) to a pure MakeMaker implementation. That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. For that matter, it's not really clear what the expected outcome of a missing build_requires requirement is as far as CPAN/CPANPLUS is concerned. Flipping through the Makefile.PLs of your modules they look for the most part trivial and would be handled fine by create_makefile_pl. smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. There is no build_requires or recommends equivalent in MakeMaker, nor will there be, so putting it into PREREQ_PM is the best thing to do. That's what every MakeMaker-based module on CPAN does after all. Its better than just dropping it and having the build fail. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. *scratch head* but if you don't have the modules necessary to BUILD the module (as opposed to those necessary to run it)... how are you going to build it? For that matter, it's not really clear what the expected outcome of a missing build_requires requirement is as far as CPAN/CPANPLUS is concerned. I'd think it would be the same as a missing requires or PREREQ_PM requirement. CPAN shells build modules. If they don't have the prerequisites to do that... well then things won't work. I don't know if the CPAN shells will attempt to build the module anyway or just refuse, but the introduction of build_requires doesn't change that behavior. Maybe there's some confusion here as to what build_requires means? Perhaps you're confusing it with the (possibly mythological) test_requires and test_recommends? Or maybe you're thinking its Module::Build requires?
Re: Test::META
Michael G Schwern wrote: On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. There is no build_requires or recommends equivalent in MakeMaker, nor will there be, so putting it into PREREQ_PM is the best thing to do. That's what every MakeMaker-based module on CPAN does after all. Its better than just dropping it and having the build fail. That's a matter of opinion; one I think should be left up to the person makeing Build.PL. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. *scratch head* but if you don't have the modules necessary to BUILD the module (as opposed to those necessary to run it)... how are you going to build it? See definition below from the docs on what build_requires [ambiguously] means. Maybe there's some confusion here as to what build_requires means? Perhaps you're confusing it with the (possibly mythological) test_requires and test_recommends? Absolutely it's confusion. http://module-build.sourceforge.net/META-spec-new.html A YAML mapping indicating the Perl modules required for building and/or testing of this distribution. These dependencies are not required after the module is installed. So, to me this means something like Test::More. It absolutely has to be in place to some *.t files to ever work, or even load. Now granted the test may end up just skipping because Test::Strict isn't instealled. In that situation, I see Test::More just as required as strict.pm. Maybe this is my issue. To me, building and testing are two different things. I don't have to test. Ever. By I do have to build the module. build_requires is a bad place for test requirements, but recommends isn't right either. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
Christopher H. Laco wrote:
Michael G Schwern wrote:
On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
That's another gripe of mine about M::B and create_makefile_pl.
It puts the requires AND build_requires in the PREREQ_PM in the
Makefile.PL, which I won't want; nor do I think it right for everyone.
There is no build_requires or recommends equivalent in MakeMaker, nor
will there be, so putting it into PREREQ_PM is the best thing to do.
That's
what every MakeMaker-based module on CPAN does after all.
Its better than just dropping it and having the build fail.
That's a matter of opinion; one I think should be left up to the person
makeing Build.PL.
err, it is up to the Build.PL author. You do the same thing you would do
with Makefile.PL, if it doesn't belong don't put it there. Simply modify
the target which in Build.PL would look something like:
use Module::Build;
my $class = Module::Build-subclass(code = 'EOF');
sub ACTION_test {
my $self = shift;
die Missing test dependency\n unless eval { use Foo::Bar; };
return $self-SUPER::ACTION_test;
}
EOF
my $builder = $class-new( ... );
$builder-create_build_script();
Maybe there should be a test_requires option, but the above isn't any
different or uglier than what MakeMaker requires.
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.
Randy.
Re: Test::META
Christopher H. Laco wrote: Michael G Schwern wrote: On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them? I rolled back. I'm have to reconsicrate my Build.PL tomorrow. I want to tinker a bit more tomorrow to rule out user stupidity. My bet is that the shebang -w in my *.t files are kicking in where they weren't before; pointing to a difference in how they're invoked between the two envorinments. Along those lines, CTRL-C, CTRL-D, and Terminate batch job.. Y never got me out of the loop: The path '' is not an absolute path. Please specify an absolute path My only recourse was to terminate the CMD window. I've seen this happen in some situations since moving to perl 5.8.x, Ctrl-Brk will work. It's not a Module::Build issue, but a perl issue. However, I'm very eager to see the conditions that caused the above failure. I'm taking time off work soon, and one of the big things I want to do (other than relax a little and play with my new Nikon D70) is improve Module::Build's test coverage and generally shore it up, getting ready for Ken to release 0.27 and the integration into perl core. So any problem reports are very valuable. There is a Module::Build list[1] if you want to bring up any issues, report problems, or just get help making the conversion. 1. http://lists.sourceforge.net/lists/listinfo/module-build-general Randy.
Re: Test::META
On Mon, Mar 28, 2005 at 06:20:32PM -0500, Christopher H. Laco wrote: Its better than just dropping it and having the build fail. That's a matter of opinion; one I think should be left up to the person makeing Build.PL. That sort of dubious flexibility is well out of the scope of Module::Build::Compat, a module intended to cover the most common conversion scenarios. build_requires is a bad place for test requirements, but recommends isn't right either. You're right, there probably should be test_requires and test_recommends. I belive the argument at the time when these things were being layed out was the tests are part of the build stage, you should always run the tests when you build. This appears to be wearing thin. Until such time as there are test_* flags, one should take a pragmatic view. And that view is what is going to cause the least amount of hassle for those who want to install my module because they don't know nor care about the internal mechanics. So you put the test requirements into build_requires and the test recommendations into recommends because those are the closest equivalents. And then you submit a patch to Module::Build to add test_requires and test_recommends. :) Looking at how create_makefile_pl works and given the lack of resolution in MakeMaker's dependency system, the obvious thing to do is to glom all the *required* Module::Build dependencies (and if there was a test_requires, that too) into PREREQ_PM so the module builds, tests and installs because nearly every Perl module build tool... A) resolves the dependencies B) builds the module C) runs the tests So Module::Build::Compat is doing the right thing. If you desire to break automated installation of your modules over an internal bit of semantics, well, I don't expect the Module::Build::Compat folks to bend over backwards to support you. You might have to write your own converter.
Re: Test::META
On Mon, Mar 28, 2005 at 07:52:22PM -0500, Christopher H. Laco wrote: Michael G Schwern wrote: Until such time as there are test_* flags, one should take a pragmatic view. And that view is what is going to cause the least amount of hassle for those who want to install my module because they don't know nor care about the internal mechanics. [snip] Sticking with ExtUtils::MakeMaker. :-) [But where's the fun in that.] I know you're joking, but you've flipped my rant switch. * The following is rant. Please scale the hyperbole down to an acceptable size * I hear a lot of complaints about Module::Build of this form: Module::Build can do X and Y but it can't do Z. I'm switching back to MakeMaker! Often, MakeMaker can't do Z either, or even X and Y! Or it takes so much hackery to get MM to do X, Y and Z that you could have patched MB nine times over in the time it took to get MM to do it. For example, the dependency nits we've been discussing. There's no point here except maybe to explain why my jaw is so often on the floor listening to Module::Build vs MakeMaker comparisons. Maybe there is a point, and I'm going to fly off into analogy here. Module::Build is like a female politian. What? Module::Build is like a female politian. Or to be even more broad, a non- white, male, christian, above the age of 35 politian. MakeMaker is the old man of Perl. Its known, working technology as someone on Perlmonks once said. We're willing to give it every benefit of the doubt because we're so comfortable with its many, many, many quirks and it works if you are running Unix, not trying to link in XS code and not doing anything too complicated. But those who understand how MakeMaker really works are horrified by it. Module::Build, otoh, is new, clean and potentially infinitely better than MakeMaker. So many features that I have to reject for MakeMaker because it would break something or require huge amounts of work and testing would be almost trivial in MB. And I point that out all the time. And that people should go spend their time on MB. With a fraction of the effort *I alone* have to spend on MakeMaker, Module::Build could blow past it in terms of functionality and reliability. But it hasn't. And I only see a small number of people patching Module::Build. And there's tons of low hanging fruit available. What's going on here? One thing I see going on is that people are holding Module::Build up to rediculously high standards. Much, much higher than MakeMaker ever was. Anything Module::Build tries to do people still nit-pick it to death, and here's the horrible part, they don't generate much patches. Take dependency resolution. MakeMaker has one way to specify a dependency. MB has a whole spectrum. And yet people still want to fall back to MM's low resolution dep system because MB's isn't quite high enough. Take create_makefile_pl. Module::Build bends over backwards to be compatible with MakeMaker. It offers not one but THREE different methods of providing that. Hell, it'll even generate a Makefile.PL that will download MB for you! And yet when people encounter small problems with it the response isn't Here's a patch or even I'll just work around that for now. No, its I'm going back to MakeMaker where they'll likely have to do more work and more work arounds to achieve the same effect. Module::Build is the female politian of Perl. It has to do things nine times better than MakeMaker to be seen as being equal. Its failures are jumped all over while MakeMaker's failures are forgiven. And despite ringing endorsements from people who really should know, such as ME, THE MAINTAINER OF MAKEMAKER AND KNOWLEDGABLE PERSON OF HOW PERL MODULES REALLY GET BUILT AND INSTALLED, I can't seem to get people to put their effort into patching MB rather than hacking around MM. Folks don't seem to want to patch MB despite it being demonstrated as being trivial compared to MM. I ported MB to VMS in a night! I made it work on MacOS Classic better than MM ever did IN THE SAME NIGHT! I recently threw away all the MacOS Classic code in MakeMaker because it was such a disaster and never really worked anyway. MakeMaker 6.26 went through TWELVE alphas trying to get VMS to work properly. *deep breaths* The point is this. * Give MB a chance. * When you encounter a problem in MB, try to patch it. * Do not expect Ken and Randy to do all the work for you. * Do not immediately run back to the warm, familiar, utterly flawed embrace of MakeMaker. Thank you. This has been a rant.
Re: Test::META
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote: On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: That's another gripe of mine about M::B and create_makefile_pl. It puts the requires AND build_requires in the PREREQ_PM in the Makefile.PL, which I won't want; nor do I think it right for everyone. There is no build_requires or recommends equivalent in MakeMaker, nor will there be, Too bad. Seems to me it would make sense to have MakeMaker support adding the tags to META.yml. Don't see what other MakeMaker change would be needed. Maybe that presupposes something else that I see as very desirable: META.yml being (re)generated by Makefile.PL at build time, and CPAN* looking in META.yml instead of Makefile for prereqs. so putting it into PREREQ_PM is the best thing to do. That's what every MakeMaker-based module on CPAN does after all. Its better than just dropping it and having the build fail. Take Test::More for example. It's usually a build_requires and the other Test* things like Test::Strict, Apache::Test, etc are in recommends. Test probably won't run with Test::More, but skipping a few subtests based on recommends is ok. But I don't think build_requires should be a PREREQ_PM requirement at all. *scratch head* but if you don't have the modules necessary to BUILD the module (as opposed to those necessary to run it)... how are you going to build it? The distinction between PREREQ_PM and build_requires only becomes meaningful for binary (that is to say, pre-built) distributions. Such distributions should be able to rely on PREREQ_PM to indicate what other (binary) distributions are required. Whether things that are required for *testing* belong in build_requires really depends on whether you view testing as an integral part of the build process. This is something that is likely to depend on the *builder*, not the module author, which is, in my mind, the only argument (and a good one) for a separate test_requires. The distinction between build_recommends and and a possible test_recommends is more ambiguous.
Re: Test::META
Randy W. Sims wrote: There is my unpublished CPAN::Metadata at: svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata It reads, writes, and validates metadata according to the spec. It still needs a bit of work, and updates to the actual spec need to be formalized before it will be usefull. Thanks... Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path So, I've sticking with ExtUtils::MakefMaker for the moment. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them?
Re: Test::META
Michael G Schwern wrote: On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote: Along the lines of converting to Module::Build...it went well until I started doing tests...things that worked now break, probably do to how they're now run... t\xsp.Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. Use of uninitialized value in transliteration (tr///) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 99. Use of uninitialized value in pattern match (m//) at C:/Development/Perl/584/lib/File/Spec/Win32.pm line 101. The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path The path '' is not an absolute path. Please specify an absolute path That's odd, its not where I'd have expected breakage. Want to post your MakeMaker and MB versions so we can poke at them? I rolled back. I'm have to reconsicrate my Build.PL tomorrow. I want to tinker a bit more tomorrow to rule out user stupidity. My bet is that the shebang -w in my *.t files are kicking in where they weren't before; pointing to a difference in how they're invoked between the two envorinments. Along those lines, CTRL-C, CTRL-D, and Terminate batch job.. Y never got me out of the loop: The path '' is not an absolute path. Please specify an absolute path My only recourse was to terminate the CMD window. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Mar 26, 2005, at 6:29 PM, Christopher H. Laco wrote: Is anyone aware of any existing code (aside from YAML) for grocking META.yml? Why are you changing it manually? -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Test::META
Andy Lester wrote: On Mar 26, 2005, at 6:29 PM, Christopher H. Laco wrote: Is anyone aware of any existing code (aside from YAML) for grocking META.yml? Why are you changing it manually? Well, unless I missed something [likely], to add things after the module is created or updated. Changing requirements, recommends, and build_requires for starters. Sometimes no_index when new modules are added to dists. Changing from the default one create with: # http://module-build.sourceforge.net/META-spec.html #XXX This is a prototype!!! It will change in the future!!! X# to the more clean/proper YAML 1.0... -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote: Well, unless I missed something [likely], to add things after the module is created or updated. Changing requirements, recommends, and build_requires for starters. Sometimes no_index when new modules are added to dists. Changing from the default one create with: # http://module-build.sourceforge.net/META-spec.html #XXX This is a prototype!!! It will change in the future!!! X# to the more clean/proper YAML 1.0... MakeMaker has very rudimentary META.yml support and is unlikely to improve in the future. Module::Build, OTOH, can handle all this for you automatically. build_requires, recommends, etc... so if you like META.yml, switch to Module::Build. Switch to Module::Build anyway.
Re: Test::META
Michael G Schwern wrote: On Sat, Mar 26, 2005 at 07:52:45PM -0500, Christopher H. Laco wrote: Well, unless I missed something [likely], to add things after the module is created or updated. Changing requirements, recommends, and build_requires for starters. Sometimes no_index when new modules are added to dists. Changing from the default one create with: # http://module-build.sourceforge.net/META-spec.html #XXX This is a prototype!!! It will change in the future!!! X# to the more clean/proper YAML 1.0... MakeMaker has very rudimentary META.yml support and is unlikely to improve in the future. Module::Build, OTOH, can handle all this for you automatically. build_requires, recommends, etc... so if you like META.yml, switch to Module::Build. Switch to Module::Build anyway. Reading...reading...reading...reading..done. Still doesn't help with the no_index problem, but it looks interesting. Can dispatch($action, %args) be used to simulate dist = PREP to autogen the pod2text README? -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Test::META
On Sat, Mar 26, 2005 at 10:14:59PM -0500, Christopher H. Laco wrote: Reading...reading...reading...reading..done. Still doesn't help with the no_index problem, but it looks interesting. I saw something about no_index on the module-build-general list just recently so maybe next version will have it.
Re: Test::META
Christopher H. Laco wrote: Is anyone aware of any existing code (aside from YAML) for grocking META.yml? I've got an itch. Aside from user side software tests, I'm also somewhat addicted to developer tests (Test::Strict, Test::Pod, etc) to make sure I'm not making stupid typo mistakes every time I upload a new version of a module. More than once now I've fubared my META.yml just enough that CPAN/Kobesearch won't touch it. I'd like to remedy that problem with a simple Test::META to check my syntax every time I make changes. There is my unpublished CPAN::Metadata at: svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata It reads, writes, and validates metadata according to the spec. It still needs a bit of work, and updates to the actual spec need to be formalized before it will be usefull.
