If you grep CPAN you'll find a lot of ad-hoc ways of asking usespace if network testing is permitted.
http://grep.cpan.me/?q=%28if|unless%29\s.%2BENV.*NET It seems wide spread enough that we may as well establish a common way of doing it, document it, and then enhance the available tooling to make it make sense. That way, instead of a user having to see a notice in their test output and manually change ENV to suit ( and have to do this many different ways for many different packages ), they'll just have to set the relevant option in their installation stack. And this would be a standard option for those running smoke testers, and smoke testers who felt that network testing was something that *should* work on their boxes could set the relevant configuration tunable, and we'll get better CPAN testers coverage as a result. Once we decide on an "official" and "blessed" ENV key, we can go about getting support for it added in various testing tools, like: https://metacpan.org/pod/Test::Is https://metacpan.org/pod/Test::DescribeMe and https://metacpan.org/pod/Test::Settings That way, Test authors only need to do: use Test::Is 'networked' ; Or similar instead of having to hand code a bunch of ENV conditions and skip rules. Though the exact syntax those modules should use can be decided at a later date and we should simply decide on the ENV name to use. Other thoughts: Some tools have their distribution name prefixed in their ENV key, which may be because those distributions consider network testing a bad idea, even if it is otherwise indicated globally as ok, and requesting *explicit* indication for itself to run. At least, that is why I imagine it is done. It may just be out of paranoia of ENV key clutter causing unintentional keys to be in scope and have people running tests without meaning to. Technically we don't really need to solve this as a feature within the ENV key, I hashed together something way more complicated that would allow per-distribution granularity settings without any specific testing/toolchain infrastructure, but it seems its not really necessary. Ultimately if a smoke tester wanted that degree of granularity, the table of rules could be established in the smoke testing toolchain itself, and per-package ENV flags could be set up to allow network tests for some dists and not for other dists using this simple approach. I also considered using values other than "1" in this ENV flag( ie: "Dist-Foo:Dist-Bar:Dist-Baz", but it all smells too much of featureitis and things we don't need yet and overcomplicates things. Essentially, the simplest thing that could work is just $ENV{NETWORK_TESTING} This is informally used in a place or two already, mimics our existing set of ENV vars, and its sensible enough that we may as well standardize on it. Competition: - A few places use NETWORK_TEST (singular) ( WWW::Offliberty, LBMA::Statistics , Net::Douban - A few places use NETWORK_TESTS (plural) ( RDF::RDFa::Template } - Quite a few places use SOMEPREFIX_NETWORK_TEST or SOMEPREFIX_NETWORK_TESTS ( Net::Social::Mapper, WorePAN, RDF::Query, RDF::Trine, Data::Feed ) - RUN_NETWORK_TESTS is seen in at least one place ( IO::Pipeley ) - Other Weird things exist: - TEST_YAR_NET_CONNECT in Net::YAR - AUTHOR_TEST_NET_ROUTE in Net::Route - HAS_INTERNET in WWW::OPG - TEST_INTERNET in WebService::CIA - PUGS_TEST_ALLOW_NETWORK in Perl6::Pugs - TEST_NET in MojoX::UserAgent - ONLINETESTS in HTTP::LoadGen - USE_NETWORK in Arch Well, you get the picture. Its a complete mess. I merely got bored with enumerating all the ways network testing could be enabled, and I doubt anyone running a smoker would care enough to track them all down like I just started to. Better to say "If you want network tests to be smoke tested, USE THIS" -- Kent ( ~KENTNL )
