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 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
Michael G Schwern wrote: 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. Yes, sir! (I love a good rant.) -ofer
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
On Mon, Mar 28, 2005 at 06:59:59PM -0800, Yitzchak Scott-Thoennes wrote: 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. Yes, it would make perfect sense except that seemingly innocent changes to MakeMaker have a tendency to break things which use MakeMaker because it is inherently fragile. For example, I reworked the way SIGNATURE and META.yml are created making them be created only in the distdir, not the source directory. This didn't break anything. What DID break Module::Install was that I added a distsign target inside the Makefile. Turns out MI had its own distsign target which it added to the Makefile. Collision. There's too many things which can go wrong. There's too many dependent modules to check. Its too much work for me. This is why I've instituted the policy of no new features. I can do this because there is a much better outlet for new features: Module::Build. I also have sneaky reasons for this policy. * less features in MakeMaker gives people more reasons to use Module::Build * less features in MakeMaker means less work for me which gives me more time to work on MB I added the rudimentary META.yml support to quickly populate CPAN with module meta-data and bootstrap the concept. Its out on its own now. 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.
