Just a wild guess: NFS (with additional complication: BSD, clang, ARM)
PERL_DL_NONLAZY=1 "/mnt/nas/home/pi2b/njh/perl5/perlbrew/perls/perl-5.24.4/bin/perl"...
Who knows where /var/tmp/ was mounted?
Perhaps, it would be a good addition to CPAN::Reporter to also list the FS-type of the relevant
directories mounted?
IFF this is an NFS/BSD issue, there's not much you could or should (if your module doesn't do the
flock;2;freebsd()) do.
Perhaps, you can add
use warnings FATAL => 'flock';
to your tests as described here: https://metacpan.org/pod/Path::Tiny#File-locking?
Edited: Misleading citation removed / still visible in HTML source.
| [reply]
[d/l]
[select] |
| [reply] |
For some weird reason, Path::Tiny uses flock before reading/writing any file, even though unixish locks are only advisory. But at least this blind checking would prevent multiple programs using Path::Tiny from clobbering each others data.
The documentation also says that you can disable the flocking by setting $ENV{ PERL_PATH_TINY_NO_FLOCK } to a true value.
| [reply]
[d/l]
[select] |
It will fail early because the pre-condition (flock() works) is not met. It will (should = untested) more clearly point out where the problem is - not in your module, but in the environment. You could wrap the exception and turn it into a more descriptive warning, providing advice on how to fix the test-environment or skip this test.
If the failure is caused by the implementation of the test case, you could fix that, i.e. by circumventing file locking or by skipping the test case (after testing capabilities) with a proper explanation.
If your module requires proper locking, it would be wise to let the test fail, perhaps with a more meaningful explanation. It might even be useful to make the warning fatal in your Anki module, if you cannot find a workaround.
The latter leads to a third option: skip test with warning / fail in production (installed module)
if pre-condition is not met.
Since your module self-tests the pre-condition, the test case could tolerate a not fully compliant test environment. However, this might break applications that (seemed to) worked fine in the past.
Everything under the assumption that NFS/flock is the real culprit.
| [reply] |
Thank you! I had a module run into the same problem, now I know the (possible) reason...
| [reply] |
Please forgive my possible naivety, but the latest version of anki_import appears to be 0.018, which begs the question: isn't it too late to either test or fix v0.012? | [reply] |
| [reply] |
I see. Thanks for the insight.
| [reply] |