Skip Menu |

This queue is for tickets about the Date-Manip CPAN distribution.

Report information
The Basics
Id: 108497
Status: rejected
Priority: 0/
Queue: Date-Manip

People
Owner: Nobody in particular
Requestors: quanah.gibsonmount [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 6.51
Fixed in: (no value)



Subject: Missing build requirement for Test::Inter
Tests depend on Test::Inter, but it is not listed as a build requirement. This causes make test to fail if Test::Inter is not present at build time.
Could you tell me exactly what you are doing to see this problem? Test::Inter is NOT a build requirement. It's a requirement to run tests, and it is specified as such in the META files, and the Makefile.PL and Build.PL files.
On Mon Nov 09 15:30:38 2015, SBECK wrote: Show quoted text
> Could you tell me exactly what you are doing to see this problem? > > Test::Inter is NOT a build requirement. It's a requirement to run > tests, and it is specified as such in the META files, and the > Makefile.PL and Build.PL files.
I clearly stated that if Test::Inter is not present when you run make test, the tests fail. Not sure how to be more clear than that. Well behaved Perl test suites will skip tests that require a test module that is not present.
On 2015-11-15 11:30:34, MISHIKAL wrote: Show quoted text
> On Mon Nov 09 15:30:38 2015, SBECK wrote:
> > Could you tell me exactly what you are doing to see this problem? > > > > Test::Inter is NOT a build requirement. It's a requirement to run > > tests, and it is specified as such in the META files, and the > > Makefile.PL and Build.PL files.
This is correct. Test::Inter is correctly listed as a test prerequisite here: https://metacpan.org/source/SBECK/Date-Manip-6.51/META.json#L43 Show quoted text
> I clearly stated that if Test::Inter is not present when you run make > test, the tests fail. Not sure how to be more clear than that. > > Well behaved Perl test suites will skip tests that require a test > module that is not present.
No, that is not correct. It is the responsibility of the installer (or the user, if installing manually) to ensure that all declared prerequisites are in place first. The specification for prerequisites is here: https://metacpan.org/pod/CPAN::Meta::Spec#Phases This is not a bug and should be closed as such.
Show quoted text
> This is not a bug and should be closed as such.
Thanks for the confirmation. That was my thought as well, though I spent a few hours looking around at SPECs and other modules to see if I was doing anything wrong. I'm closing this ticket with no change to the module.
On Mon Nov 30 07:48:12 2015, SBECK wrote: Show quoted text
> > This is not a bug and should be closed as such.
> > Thanks for the confirmation. That was my thought as well, though I > spent a few hours looking around at SPECs and other modules to see if > I was doing anything wrong. > > I'm closing this ticket with no change to the module.
I love it when people hide behind process documentation to avoid improving code. So lets talk facts: fact #1) Plenty of other authors make the effort to ensure their test suite doesn't blow up if a test module is missing fact #2) It's trivial to do this fact #3) There are numerous perl test modules, many of which are not provided by downstream distributions (linux, *bsd, etc). I have gone down the rabbit hole of trying to provide every test module for every perl module I build out. That led to nearly 100 additional modules becuse of the requirements the various test modules have as well. Just because author X decided to pick some flavor of the day for a test module is not my issue fact #4) There is nothing invalid about a request to enhance/improve the test suite for a module so that it handles the missing module gracefully.
On Mon Nov 30 09:50:37 2015, MISHIKAL wrote: Show quoted text
> On Mon Nov 30 07:48:12 2015, SBECK wrote:
> > > This is not a bug and should be closed as such.
> > > > Thanks for the confirmation. That was my thought as well, though I > > spent a few hours looking around at SPECs and other modules to see if > > I was doing anything wrong. > > > > I'm closing this ticket with no change to the module.
> > > I love it when people hide behind process documentation to avoid > improving code. So lets talk facts: > > fact #1) Plenty of other authors make the effort to ensure their test > suite doesn't blow up if a test module is missing > > fact #2) It's trivial to do this > > fact #3) There are numerous perl test modules, many of which are not > provided by downstream distributions (linux, *bsd, etc). I have gone > down the rabbit hole of trying to provide every test module for every > perl module I build out. That led to nearly 100 additional modules > becuse of the requirements the various test modules have as well. > Just because author X decided to pick some flavor of the day for a > test module is not my issue > > fact #4) There is nothing invalid about a request to enhance/improve > the test suite for a module so that it handles the missing module > gracefully.
Just as an example, here's a *well written* test: t/00-pod.t ................. skipped: test requires Test::Pod 0.95 and POD "=encoding" support from Net::DNS
I wanted to comment on this one last time because I have been giving this some thought to decide if I should add the workaround suggested here. I have come to a concrete decision about this, and I will NOT be adding the workaround. Here is my reasoning. When you install a module, I obviously want you to run the tests. You're free to not do so of course, but I hope that you will run them. I want my tests to do two things: 1) If there is a problem, I want a failure to occur. If a success occurs, then that's a false positive. 2) If there is not a problem, I want a success to occur. If it fails, that's a false negative (broken test). In order for you to run the tests, it requires the Test::Inter module, and I have told you, in the manner specified by best practices and standards, that it is a requirement. I.e. I have listed it in the appropriate META files as a prerequisite to running the tests. If I were to go and add a test to the top of every test to see if Test::Inter is there, and if not, just skip all the tests, then when you run tests, it will appear like you have successes for all of the tests. In other words, there was a problem (though in this case, the problem is that you were missing Test::Inter, and is not actually related to Date::Manip) but the test succeeded (or at least did not fail). So you didn't actually run any of the tests. I don't want that result. I would hope that you wouldn't want it either. I would hope that you would see "oops, there's a problem, and in this case it is a problem with my environment rather than a problem with the Date::Manip module". You would then fix the problem (by installing Test::Inter) and rerun the tests. Once that's done (i.e. you've corrected your test environment), then running the tests gives meaningful information about the Date::Manip module. Hopefully it shows that it works fine, but if it fails, then it may mean that you have found a bug in the module that only manifests itself in some situations, and hopefully you'll let me know. In either case, you've actually exercised the Date::Manip module. If you want to skip running the tests, fine, but if you want to run the tests, I would hope that you would actually want meaningful results rather than just a checkmark in the list of install step. I realize (as you've demonstrated) that other modules have chosen to add the check at the top of each test script, and I'm fine with them doing that... but I choose not to do so for so that the tests will actually reflect problems/successes in Date::Manip as opposed to something outside of the realm of that module. Hopefully this clarifies things a bit.