I propose to drop support for SRC_TEST with EAPI=3. We can RESTRICT=test if needed.
(In reply to Torsten Veller (RETIRED) from comment #0) > I propose to drop support for SRC_TEST with EAPI=3. > We can RESTRICT=test if needed. Excellent idea, maybe we can do it with EAPI=6. O:)
I believe SRC_TEST=parallel or similar will still be necessary. Though I think we should start to default parallel testing to be *on* and then disable it when it breaks. Just the downside of that is there are some packages upstream that have a tendency to lock indefinitely, or in some cases, consume all disk space when run under parallel testing. The situation is constantly improving and I've been having parallel testing the *default* when using the cpan toolchain now for a long time with very few problems. But there will still be residual bugs. Additionally, we need some way of mapping any applicable "please don't do network-enabled testing" restrictions to perl space so that distributions which mix network-enabled and non-network-enabled test can still run. ( as is, simply making network connections die can cause tests to fail ). Upstream seems to be forming around the use of NO_NETWORK_TESTING as a way for systems to indicate the network can't expected to be work.: - https://metacpan.org/pod/Test::RequiresInternet - https://metacpan.org/source/TOBYINK/Test-Modern-0.013/lib/Test/Modern.pm#L167 - http://stackoverflow.com/a/25634365/15614 - http://grokbase.com/t/perl/cpan-workers/146brgeqqm/rfc-consensus-on-network-testing-env Yes ... that is my comment in that last one. ( And incidentally, some of my arguments presented are due to thinking about gentoo ... )
(In reply to Kent Fredric from comment #2) > I believe SRC_TEST=parallel or similar will still be necessary. > > Though I think we should start to default parallel testing to be *on* and > then disable it when it breaks. ++ In general we should default testing to on and only disable it when it breaks. > Additionally, we need some way of mapping any applicable "please don't do > network-enabled testing" restrictions to perl space so that distributions > which mix network-enabled and non-network-enabled test can still run. > [...] > Yes ... that is my comment in that last one. ( And incidentally, some of > my arguments presented are due to thinking about gentoo ... ) Awesome, thanks. Maybe we should also think about renaming the variable in EAPI=6, e.g. for a common prefix of all perl-module.eclass vars. PERL_SRC_TEST? PERL_TEST?
> Maybe we should also think about renaming the variable in EAPI=6, e.g. for a > common prefix of all perl-module.eclass vars. > > PERL_SRC_TEST? PERL_TEST? /all/ seems a bit over zealous, I would be loath to need GENTOO_PERL_MODULE_AUTHOR= instead of MODULE_AUTHOR= etc. I think within reason we can use any variable name we want as long as we make doubly sure they don't leak outside the ebuild into Perl space ( perhaps some sort of post-source env cleanup step if necessary, but I don't think it is, can't remember ). Just I'd shy away from variables with very simple PERL_* names for gentoos use, even if they can't leak, mostly due to being potentially confusing. I think the shortest I can think of that is clearly a "Gentoo Perl" prefix would be say, for instance, GXPL_ ( because GPL is obviously GNU Public License not Gentoo PerL ), with the X borrowed from "gx86". I could live with GXPL_MODULE_AUTHOR and not want to go around stabbing people every time I had to write it. Incidentally, you may have noticed I basically implemented exactly this plan on the overlay in its *current* perl-module.eclass for the whole tree ;) https://github.com/gentoo-perl/perl-experimental/blob/master/metadata/news/2014-10-11-perlmodule-eclass-tests/2014-10-11-perlmodule-eclass-tests.en.txt https://github.com/gentoo-perl/perl-experimental/commit/fa40465a56e6b0f5484c8a1994d3270ee0316d38?diff=unified Nobody appears to have complained yet.
Let's close this bug, the variable will be renamed but essentially something similar will remain.
