Tests failing for third party server lapses

Sixtease has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Tests failing for third party server lapses by moritz (Cardinal) on Nov 04, 2008 at 07:56 UTC
Modify your Makefile.PL so that it downloads the definitions file, and if that fails prints out a nice, informative error message and refuses to write a Makefile. That way you will get NA reports instead of FAIL reports, and your users will know what's going on.	[reply]
Re^2: Tests failing for third party server lapses by Sixtease (Friar) on Nov 04, 2008 at 08:18 UTC
This is great, thank you, exactly what I needed to hear. :-) Just how exactly do I make it produce NA instead of FAIL? Link to docs will do. use strict; use warnings; print "Just Another Perl Hacker\n";	[reply]
Re^3: Tests failing for third party server lapses by moritz (Cardinal) on Nov 04, 2008 at 08:39 UTC
"How can I stop getting FAIL reports for missing libraries or other non-Perl dependencies?" If you have some special dependencies and don't want to get CPAN Testers reports if a dependency is not available, just exit from the Makefile.PL or Build.PL normally (with an exit code of 0) before the Makefile or Build file is created.	[reply]
Re: Tests failing for third party server lapses by brian_d_foy (Abbot) on Nov 04, 2008 at 10:14 UTC
Can you bundle a minimal set of files just for testing? How about mirroring the files that you need on another server (say, like a Google Code project)? Also, you can skip tests if you don't have everything that you need to test. I wouldn't refuse to write a Makefile because that stops everyone from installing the source even though the module probably still works. Print out a nice message saying they need to download some files later and still test what you can. -- brian d foy <brian@stonehenge.com> Subscribe to The Perl Review	[reply]
Re: Tests failing for third party server lapses by mje (Curate) on Nov 04, 2008 at 13:12 UTC
As others have said, I'd try and include some of the test files with your distribution or add a second place to get them in case of busy servers. However, you are still best skipping tests where you cannot perform the test rather than failing to generate a Makefile since the person installing will not be able to install even if it would have worked. I'm not smoke testing currently but I was until a few weeks ago. A number of distributions I tested which required HTTP access failed because they paid no attention to my http_proxy environment variable and hence could not get HTTP to work e.g., they did not call env_proxy in LWP.	[reply]
Re: Tests failing for third party server lapses by Gurft (Novice) on Nov 05, 2008 at 16:16 UTC
The idea of having to go out and download something in order for your module to build always seems like a "bad idea" to me, especially for users that are installing your module onto systems that do not have internet access (like those of us living behind corporate firewalls) I would try to include the latest entity definitions from w3 as of the version of the module you're releasing and provide the user the option to download the latest/greatest or provide documentation of how to manually go get it instead of making it part of the automated build process.	[reply]
Re^2: Tests failing for third party server lapses by Sixtease (Friar) on Nov 06, 2008 at 15:35 UTC
There was discussion about this earlier. People adviced me to have the entities always downloaded to 1) avoid having to keep a list of entities up to date and 2) keep the module significantly smaller. I'm now thinking of creating another module, which would only contain the definitions. But then I'd need to depend either on it or on www access. Can something like that be represented? use strict; use warnings; print "Just Another Perl Hacker\n";	[reply]