Don't do like V: never ever turn off the WARNING mode in logging

[valeriupredoi]

Here's a quick story: one CMORizer script spits out a ton of warnings from iris (thanks, Obama! 😁 ), so I, like an entrerprizing yet lazy software engineer, I decided that, instead of complicating myself with filtering iris warnings in the pytest configuration, I can just turn off the WARNING channel inside the script with the benign logging.disable('WARNING'). Done and dusted, all went fine, no more annoying warnings from iris, and my new tests for the respective CMORizer module were passing all nicely. Until I noticed some other test module was failing, apparently unrelated to the changes I made. So I went on a debugging trail that immediately revealed that that test was failing because the expected output to be read from a file wasn't there anymore (the file was empty); but the funny thing was that the test, if run as standalone, would pass, it'd only fail if run in the test suite. So I narrowed it down that the new test module I wrote, if run together with this guy, would provoke a fail of the latter - now, which one of the 9 tests inside the new pytest module was causing the older test module to fail? I @pytest.mark.skip(reason="...") tests up and down the module, and reran, to a point where I skipped all the tests- and still, the old test module would fail. So, methinks - gotta be an import that is causing this cluster..ahem...you catch my drift! The only import that would cause some trouble was the one that got stuff from the new CMORizer, that - you guessed it by now - had that logger WARNING suppression statement in it - Eureka! That was it - I commented that line out and my tests are now passing nicely. Moral of the story: don't turn off the logging WARNING channel anywhere in a module that gets imported since that's a global setting, and worst of all, suppresses pytest output to files that is piped as WARNING, and not just as INFO (yes, to stdout and console, rather than INFO that's piped to console only) 😁