Andreas Koenig <andreas.koenig.7os6v...@franz.ak.mind.de> writes:
>>>>>> On Sun, 21 Jan 2018 22:18:12 +0100, Slaven Rezic <sla...@rezic.de> said:
>
> >> 6. Not every CPAN contributor writes tests that allow execution of
> >> tests in parallel, or even to run in parallel with another perl
> >> executing the same tests at the same time.
>
> > This would be an interesting thing to have, but I always thought that
> > the specification should go into the distribution's META.* files (wasn't
> > there already a proposal?). And CPAN.pm may inject changes into the META
> > information via distroprefs files (at least this is possible for
> > dependency information).
>
> My smokers nearly always run several instances of different perls
> simultaneously on the same server. Other smokers, e.g. Ether's, have
> HARNESS_OPTIONS set up for parallel runs.
>
> The number of issues caused by that seem to be negligible, so I always
> wrote bug reports like these:
>
> https://rt.cpan.org/Ticket/Display.html?id=98239
> https://rt.cpan.org/Ticket/Display.html?id=85336
> https://rt.cpan.org/Ticket/Display.html?id=85303
> https://rt.cpan.org/Ticket/Display.html?id=85301
> https://rt.cpan.org/Ticket/Display.html?id=84333
>
> I don't find more than these 5, so either I was bad in identifying the
> cases or the issue is not very wide-spread.
By running several instances in parallel you see only one possible
problem case, usually caused by the test scripts using the same resource
(tcp port, same (predictable!) file in /tmp etc.).
When using HARNESS_OPTIONS=jX there are other problem cases. Test suites
may assume a special order running the test files. E.g. the first test
script may create some file setup in the local build directory, or setup
a server with a random port and write down the port for subsequent test
scripts to use, and the last test script may collect results of the
former test scripts.
>
> I also argued in the past that asking for metadata should be avoided
> because:
>
> - authors usually do not know
> - metadata age
> - harnesses change
> - should the need really exist, we should first collect data what kinds
> of problems we have and how they can be dealt with besides metadata
The good thing is that the specification would be completely optional,
both for authors to specify and test runners to use. If it's not given
then a conservative default (no testing with HARNESS_OPTIONS=jX) should
be used. But if it's there, then we can speed up the installation of
modules, which may matter in some environments.
Another good thing is that the specification is quite simple: the
possible values would be "yes", "no", nothing more needed.
(The other approach to speed up module installations is to use a
parallel CPAN installer like cpm --- but this approach also has its
subtle problems)
Regards,
Slaven
--
Slaven Rezic - slaven <at> rezic <dot> de
BBBike - route planner for cyclists in Berlin
WWW version: http://www.bbbike.de
Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
