On Sun, Sep 11, 2005 at 12:35:43PM -0500, Andy Lester wrote: > >Usually, Test::* modules are only used for the test phase. > > I really don't understand the idea of "only used for the test phase", > as if the tests don't matter, or if there are levels of failure. > Either they install OK on the target system, and you can use them > with confidence, and they've done their job, or you're going to > ignore the tests completely and then who needs 'em? > > It's like if I'm installing a washing machine, and I don't have a > level. I can say "Ah, I only need it for the installation, and it > looks pretty level, so I don't need the level", or I can say "I'm not > using this appliance until I've proven to myself that the machine is > level and won't cause me any problems in the future because of an > imbalance."
This is a good analogy. It's correct. But the assumptions behind it cover only one case. It's as if the requirements for the washing machine say: To install and use this machine you will need: * a power supply * a water supply * drainage * a level which is valid if you're both the installer and the user. But if someone else helps you install the machine, then you don't actually need the level, if they bring theirs and use it for the install. I think that the build_requires/test_requires distinction *is* important, if it can be made, as it eases the lives of anyone wishing to package up modules, build them from source in one place, and then distribute their packages to many other machines, be they OS vendors or sysadmins. The tests are run and pass on the build machine, prior to packaging. But the automatic dependency system doesn't need to make installation of this module depend on installing Test::* onto the production machine. (for the general case) But it's only important if it's easy to make. And I'd much prefer time and effort to go into writing better modules, better tests, and better tools, than generating heat. Nicholas Clark