Last night I released Devel::CheckOS and Devel::AssertOS. They are a wrapper around $^O with some extra functionality. For example, where you can check $^O's value to see if you're running on a Linux system, you can use these modules to check for OS 'families' as well, such as whether you're running on a Unix system.
Devel::CheckOS provides functions which return true or false depending on whether there's a match. Devel::AssertOS dies when you try to use it if there's no match.
The intention is that authors will use these modules whenever they write platform-specific code so that it will die with an appropriate message, which will be picked up by CPAN testers, and make them SHUT THE HELL UP when they try to do stupid things like test Solaris::Foo on Linux or VMS::Bar on Windows.
Re:Why two modules?
drhyde on 2007-10-02T17:48:56
It's two modules because merely asking "is this a Unix system?" is different from asserting that "this must be a Unix system". Actually, CheckOS can do the assertion as well, but I thought that cutting the amount of code required to make the assertion to the absolute minimum would be a good idea seeing that that will, I think, be the most common usage.
Dependency hell? Hardly. Declare it as a pre-requisite and CPAN.pm will do the business. If you're not using CPAN.pm to fetch and install dependencies then you're in dependency hell already and this won't make things noticeably worse. The real dependency hell is tracking down and installing the C libraries that some modules depend on. I agree that depending on a zillion modules is a bad idea though - my cpandeps site is the proof of that. However, that doesn't mean that I should never release code for other people to use. It just means that people should be careful about what they choose to use. If they choose not to use this I promise not to get upset. And as it happens, I've checked the failure reports and decided that they're not going to affect this. They all appear to have come from broken systems.
As for whether it's a waste of space, if you can come up with a better way of telling the build systems that Some::Random::Module depends on SomeOS, and A::Different::Module depends on you running any of SeveralOSes, then I'm all ears. Right now, code to figure this stuff out lives in several places. Re-factoring it is a Good Thing. And also remember that I'm also responsible for the great bit fat bloated distribution that is Number::Phone. If you really want to berate me for filling up CPAN mirrors' disks, that would make a much better target for your ire! Compared to that, the 9K that this distribution eats is utterly insignificant.
One of the most common grumbles I get from module authors when I test their code is along the lines of "It's called Linux::Foo, of course it won't work on Solaris!". There's now a way for authors to specify OS dependencies so in time the CPAN testers will shut the hell up with those stupid test failure reports. In fact, it's a discussion along those lines that prompted me to write it. Better that they use a module one of whose prime concerns is that it Do The Right Thing Everywhere than that they just cut n paste code from somewhere else, test it on Linux, and just assume that that's enough. True, I've not been able to test it everywhere, but I *will* work to fix them if I ever hear of a problem. The whole raison d'être of this is that it works everywhere, even if you're the one person left in the whole world using perl on Netware 3.
Re:Why two modules?
dagolden on 2007-10-02T20:20:59
For this to work in a Makefile.PL or Build.PL, it can't be an ordinary dependency. It will either need to be a "configure_requires" -- for which support is only available in recent versions of CPAN, or it will need to be bundled into an "inc" directory -- the preferred course, I think.
# Makefile.PL
use lib 'inc';
use Devel::AssertOS::Unix;
# rest of Makefile.PL follows;This would ensure that the OS is a Unix variant or else it will die (signaling to CPAN to stop with build/test/install) and with a properly formatted error string for CPAN Testers clients to avoid triggering a FAIL report.
What I'd like to see next (and have discussed with David at least a little bit) is getting it to automatically bundle itself into "inc" or writing another module that would do so. (Module::Install, of course, probably would, but that's another set of issues entirely.)
-- dagolden
Re:Why two modules?
drhyde on 2007-10-02T22:01:27
The shiny new File::Find::Rule::Permissions I released uses Devel::AssertOS::Unix in the module. So it'll get as far as trying to run the tests on non-Unix platforms, then bail out with 'OS unsupported', which is close enough for now.
Schwern has mumbled about releasing some inc thingy for EU::MM. Perhaps in the mean time I should add a 'add_develassertos_inc' script to the distribution which would do everything necessary to a Makefile.PL in the current directory:
$ add_develassertos_inc FreeBSD NetBSD OpenBSDto add a dependency on any one of the BSDs, for example.
Further discussion by email please
:-)
