> Michael Graham wrote: > > Another good reason to ship all of your development tests with code is > > that it makes it easer for users to submit patches with tests. Or to > > fork your code and retain all your development tools and methods. > > Perl::MinimumVersion, which doesn't exist yet, could check that the > version a module says it needs is higher than what Perl::MinimumVersion > can work out based on syntax alone. > > And it uses PPI... all 55 classes of it... which uses Class::Autouse, > which uses Class::Inspector, and prefork.pm, and Scalar::Util and > List::Util, oh and List::MoreUtils and a few other bits and pieces. > > I'm not going to push that giant nest of dependencies on people just so > they can install Chart::Math::Axis...
I'm not suggesting that end users be forced to *run* your development tests. Just that the tests be included in your CPAN package. Ideally, the install process can be made smart enough to skip this kind of test. > So I run it in my packaging pipeline. It's a low percentage test that > catches some annoying cases that bite me once a year. > > And I should probably not talk about the RecDescent parser for the > bundled .sql files, or the test that ensures that any bundled .gif files > are at something close to their best possible compression level. If someone were to take over maintenance of your module, or they were to fork it, or they were submitting patches to you, then they would want these tools and tests, right? How would they get them? Michael ----------------------------------------------------------------------- Michael Graham <[EMAIL PROTECTED]> YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED] -----------------------------------------------------------------------
