Discussion:
Why does File::Path not respond to 'cover'?
James E Keenan
2015-06-27 02:08:23 UTC
Permalink
Richard Elberger and I recently received co-maintenance bits on the
File-Path distribution. As is my wont, I ran it through Devel::Cover --
but was surprised to see that 'cover' reported zero coverage.

#####
$ perl Makefile.PL && make
Generating a Unix-style Makefile
Writing Makefile for File::Path
Writing MYMETA.yml and MYMETA.json
Skip blib/lib/File/Path.pm (unchanged)
Manifying blib/man3/File::Path.3

$ HARNESS_PERL_SWITCHES=-MDevel::Cover make test
PERL_DL_NONLAZY=1
/home/jkeenan/perl5/perlbrew/perls/perl-5.20.1/bin/perl
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
*Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Path-Class.t .. ok
t/Path.t ........ 1/152 bug487319/symlink for bug487319/symlink: No such
file or directory at t/Path.t line 369.
t/Path.t ........ ok
t/pod.t ......... skipped: PERL_AUTHOR_TESTING environment variable not
set (or zero)
t/taint.t ....... ok
All tests successful.
Files=4, Tests=190, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.99 cusr
0.03 csys = 1.06 CPU)
Result: PASS

$ cover
Reading database from /home/jkeenan/gitwork/File-Path/cover_db


----------------------------------- ------ ------ ------ ------ ------
------
File stmt bran cond sub time
total
----------------------------------- ------ ------ ------ ------ ------
------
blib/lib/File/Path.pm 0.0 0.0 0.0 0.0 n/a
0.0
Total 0.0 0.0 0.0 0.0 n/a
0.0
----------------------------------- ------ ------ ------ ------ ------
------


HTML output written to
/home/jkeenan/gitwork/File-Path/cover_db/coverage.html
done.
#####

I hypothesized that perhaps results would be different if I were to move
./Path.pm to lib/File/Path.pm -- but I got the same results.

Does anyone know why File-Path is unresponsive to 'cover'?

Thank you very much.
Jim Keenan
yary
2015-06-27 17:55:09 UTC
Permalink
I believe that Devel::Cover excludes core modules, so that "your code"
isn't influenced by modules that are included (perhaps indirectly). Seek
out a switch/hash/regexp/sub to modify that behavior, there is one
somewhere!

-y
Post by James E Keenan
Richard Elberger and I recently received co-maintenance bits on the
File-Path distribution. As is my wont, I ran it through Devel::Cover --
but was surprised to see that 'cover' reported zero coverage.
#####
$ perl Makefile.PL && make
Generating a Unix-style Makefile
Writing Makefile for File::Path
Writing MYMETA.yml and MYMETA.json
Skip blib/lib/File/Path.pm (unchanged)
Manifying blib/man3/File::Path.3
$ HARNESS_PERL_SWITCHES=-MDevel::Cover make test
PERL_DL_NONLAZY=1 /home/jkeenan/perl5/perlbrew/perls/perl-5.20.1/bin/perl
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef
*Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/Path-Class.t .. ok
t/Path.t ........ 1/152 bug487319/symlink for bug487319/symlink: No such
file or directory at t/Path.t line 369.
t/Path.t ........ ok
t/pod.t ......... skipped: PERL_AUTHOR_TESTING environment variable not
set (or zero)
t/taint.t ....... ok
All tests successful.
Files=4, Tests=190, 1 wallclock secs ( 0.04 usr 0.00 sys + 0.99 cusr
0.03 csys = 1.06 CPU)
Result: PASS
$ cover
Reading database from /home/jkeenan/gitwork/File-Path/cover_db
----------------------------------- ------ ------ ------ ------ ------
------
File stmt bran cond sub time
total
----------------------------------- ------ ------ ------ ------ ------
------
blib/lib/File/Path.pm 0.0 0.0 0.0 0.0 n/a
0.0
Total 0.0 0.0 0.0 0.0 n/a
0.0
----------------------------------- ------ ------ ------ ------ ------
------
HTML output written to
/home/jkeenan/gitwork/File-Path/cover_db/coverage.html
done.
#####
I hypothesized that perhaps results would be different if I were to move
./Path.pm to lib/File/Path.pm -- but I got the same results.
Does anyone know why File-Path is unresponsive to 'cover'?
Thank you very much.
Jim Keenan
James E Keenan
2015-06-28 13:18:57 UTC
Permalink
Post by yary
I believe that Devel::Cover excludes core modules, so that "your code"
isn't influenced by modules that are included (perhaps indirectly). Seek
out a switch/hash/regexp/sub to modify that behavior, there is one
somewhere!
-y
Post by James E Keenan
Richard Elberger and I recently received co-maintenance bits on the
File-Path distribution. As is my wont, I ran it through Devel::Cover --
but was surprised to see that 'cover' reported zero coverage.
Does anyone know why File-Path is unresponsive to 'cover'?
Thanks, yary. Yes, after I posted I recalled that Devel::Cover does
exclude core modules. IIRC, pjcj had a project called 'p5cover' which
was intended to rectify that, but I don't know that project's current
status.

In any case, on my previous laptop I located some correspondence with
pjcj from two years ago in which I reported having found a hack for this
case: Create a branch. In the branch rename 'Path.pm' to something
like 'ABCPath.pm', then do a global search-and-replace in all files
(except things like README, TODO and Changes) to impose the new name.
At that point you can run 'perl Makefile.PL && make', and from that
point Devel::Cover sees a brand new library and calculates coverage.

Thank you very much.
Jim Keenan
Aristotle Pagaltzis
2015-06-28 14:13:19 UTC
Permalink
Post by James E Keenan
In any case, on my previous laptop I located some correspondence with
pjcj from two years ago in which I reported having found a hack for
this case: Create a branch. In the branch rename 'Path.pm' to
something like 'ABCPath.pm', then do a global search-and-replace in
all files (except things like README, TODO and Changes) to impose the
new name. At that point you can run 'perl Makefile.PL && make', and
from that point Devel::Cover sees a brand new library and calculates
coverage.
That’s very invasive to the code being instrumented, though. Hacking the
exemption out of Devel::Core seems like the far more robust alternative.
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Paul Johnson
2015-06-28 15:43:56 UTC
Permalink
Post by James E Keenan
Post by yary
I believe that Devel::Cover excludes core modules, so that "your code"
isn't influenced by modules that are included (perhaps indirectly). Seek
out a switch/hash/regexp/sub to modify that behavior, there is one
somewhere!
I'm not convinced this is the problem because the file is actually being
reported on, it's just that the report says the coverage is 0.

Devel::Cover doesn't ignore core modules in the sense that it knows
which modules are core and alters behaviour for them. But it does have
ways of ignoring modules either based on their names or their locations.
By default all of the modules in all of the directories of a pristine
@INC are ignored. This effectively ignores core modules and all other
installed modules which, usually, is what you want. Ignore here means
not to collect coverage data. The code is obviously still run.

If Devel::Cover has got things wrong then this can all be altered with
command-line options, you shouldn't have to go grovelling around the
code.

However, in this case, the modules have not been installed and so they
won't be in that location and, by default, will not be ignored. This is
why the coverage is reported, albeit as 0.
Post by James E Keenan
Post by yary
Post by James E Keenan
Richard Elberger and I recently received co-maintenance bits on the
File-Path distribution. As is my wont, I ran it through Devel::Cover --
but was surprised to see that 'cover' reported zero coverage.
Does anyone know why File-Path is unresponsive to 'cover'?
I think the problem here is that Devel::Cover cannot provide coverage
for modules it uses itself. For this reason I try to keep Devel::Cover
dependencies to a minimum. File::Path, however, is one of the
dependencies. This is described in to docs:
https://github.com/pjcj/Devel--Cover/blob/master/lib/Devel/Cover.pm#L1611

This means, I'm afraid, that there is no easy solution to getting
Devel::Cover to run with File::Path.
Post by James E Keenan
Thanks, yary. Yes, after I posted I recalled that Devel::Cover does
exclude core modules. IIRC, pjcj had a project called 'p5cover'
which was intended to rectify that, but I don't know that project's
current status.
Languishing, I'm afraid. But even if it were working it could not
provide useful data for File::Path for the reason mentioned above.
Post by James E Keenan
In any case, on my previous laptop I located some correspondence
with pjcj from two years ago in which I reported having found a hack
for this case: Create a branch. In the branch rename 'Path.pm' to
something like 'ABCPath.pm', then do a global search-and-replace in
all files (except things like README, TODO and Changes) to impose
the new name. At that point you can run 'perl Makefile.PL && make',
and from that point Devel::Cover sees a brand new library and
calculates coverage.
Yes. This works because the module is then separate from the standard
File::Path. I suppose a solution could be to bundle File::Path with
Devel::Cover but under a different name. Or perhaps take the parts of
File::Path which Devel::Cover uses and "inline" them somehow. The same
argument could be used for the other modules Devel::Cover uses itself.
I am not enamoured of these options but they might bear thought.

Devel:Cover is also unable to provide coverage for itself, for the same
reason. I have worked around that partially within Devel::Cover by
providing a reduced coverage option which uses the older method of
replacing the runops loop rather then replacing function pointers for
ops, and doesn't suffer from the same deficiency.

There is a small chance that you might get coverage for File::Path by
setting DEVEL_COVER_OPTIONS=-replace_ops,0 but I have not tried it and
wouldn't like to bet on it. But if it doesn't work and anyone would
like to dig into it, that is where I would start.
--
Paul Johnson - ***@pjcj.net
http://www.pjcj.net
Loading...