Test coverage has nothing to do with module installation. However, build systems are for both those who install modules and those who create modules. Otherwise, it might make more sense to call this Module::Install or Module::Create. Since you can't have the former without the latter, why create a build system that only caters to one segment? I am not suggesting that this be one of the first features put in there, but it would be a valuable one.
Test coverage is an important (but neglected) part of ensuring software quality. Any tool that makes it easier to provide better quality software can only help Perl.
| [reply] |
I thought we were talking about the module installer in the top post. Maybe the name "Module::Build" is not well chosen (and Module::Install is a better name but also exists already).
I see that test coverage and test running are tightly coupled, but I think that both are best done via Test::Harness and/or prove and not within the module installation kit.
Otherwise, inclusion of CPAN upload could go in as well, as upload to sourceforge. And an announcement on p5p and/or modules@perl.org ...
| [reply] |
Yes, I think you're right that it should be in Test::Harness or something similar. However, I would like to see readily available hooks available, just as we have (?:make|Build) test.
If all dragonchild wants to do is install modules, though, then Module::Build is a bad name.
| [reply] |
Well, users need to run tests,
and developers shouldn't be encouraged to break TEST_VERBOSE=1 .... the less developers have to invent, the more useful cpan-tester results become
update: what I'm trying to say is that everyone needs a good uniform experience from the start, so they can focus on more important things
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |