--omit and --include from Zooko

[Ned Batchelder]

I've merged Zooko's --omit and --require feature, but with a few changes:

1) I renamed --require to --include.
2) You can use both together, including is done first, then omitting.
3) I added some tests
4) The command-line switches weren't hooked up to the run command, they
are now.

Zooko, thanks for getting this ball rolling, it's been long overdue!

Things I'm still mulling over:

1) It feels odd to me to pass in omit_prefixes and include_prefixes to
both the coverage constructor and each of the reporting functions. The
constructor needs it for run, and the reporting functions need it for
backward compatibility.
2) The docstrings get really repetitive!

--Ned.

[Zooko O'Whielacronx]

> 1) It feels odd to me to pass in omit_prefixes and include_prefixes to both
> the coverage constructor and each of the reporting functions.  The
> constructor needs it for run, and the reporting functions need it for
> backward compatibility.

You might want to trace only a subset of the directories at run time
(for speed), and then you might want later to emit reports on
different subsets of that subset.

> 2) The docstrings get really repetitive!

True. I figured if you were just diving in and looking at a single
docstring (for example if you were using the builtin 'help' function
of CPython to look at a single function) then it would be useful to
restate the meaning of those vars. I wouldn't object if you remove
them and reorganize the doc to how you like, though,

Regards,

Zooko

[Ned Batchelder]

The longest-standing request for coverage.py is to be able to exclude
files with patterns of some kind. I finally decided that the way to do
this is to break backward compatibility, and have the --omit argument be
filename patterns.

So, no more prefixes. You can append a star or a slash-star to the
prefix to get what you want.

And no regexes: fnmatch-style patterns are more appropriate.

This is all pushed up to the repo, comments welcome.

--Ned.

[simon thepot]

Great ! :)

Hi, I just glance through your patch, and it looks good to me.
Btw, it seems (but I may be mistaken) you just take into account those omit/require options while reporting.
I was just simply wondering, if it was possible/interesting to use them as you were measuring coverage (only mesure what you are going to report) ; I think it may have not much interest, but I was just wondering.

Cheers !

Simon Thepot aka djcoin

2010/5/23 Ned Batchelder <n...@nedbatchelder.com>

[Ned Batchelder]

Actually, Zooko's original patch included using the two switches to control the measurement phase also.  For example, see http://bitbucket.org/ned/coveragepy/src/tip/coverage/control.py#cl-183 .

--Ned.

[zooko]

Looks like doc/cmd.rst needs to be updated.

Thanks for the good work, Ned!

[Zooko O'Whielacronx]

On Thu, Jun 3, 2010 at 7:27 PM, Ned Batchelder <n...@nedbatchelder.com> wrote:
> Yes, I do docs last as part of releasing a version.
>
> Also, I'm thinking of another twist to this: usually, the way people want to
> describe a pile of source code is in terms of the roots of trees: either a
> package or a directory.  To make this possible, I'd like to add a
> --source=XYZ option that would be like --include, but would include the
> entire tree rooted at XYZ, which is either a Python package name or a
> directory.  This I think will mesh well with people's instincts about how to
> talk about code.  The current arguments to the reporting commands will be
> extended to work this way also.

That's how I'm already using it:

http://tahoe-lafs.org/trac/trialcoverage/browser/trialcoverage/trialcoverage.py?rev=30#L99

Actually that's not quite right. Here, updated for your new API and fixed:

http://tahoe-lafs.org/trac/trialcoverage/browser/trialcoverage/trialcoverage.py?rev=34#L89

Regards,

Zooko

[Ned Batchelder]

Yes, I do docs last as part of releasing a version.

Also, I'm thinking of another twist to this: usually, the way people
want to describe a pile of source code is in terms of the roots of
trees: either a package or a directory. To make this possible, I'd like
to add a --source=XYZ option that would be like --include, but would
include the entire tree rooted at XYZ, which is either a Python package
name or a directory. This I think will mesh well with people's
instincts about how to talk about code. The current arguments to the
reporting commands will be extended to work this way also.

--Ned.

[memedough]

Hi,

I've been playing with the fnmatch style include / omit and it works
nicely. I also appears to affect measurement collection as well as
reporting.

How does the proposed source option fit in? I mean does include /
omit operate within the specified source roots? Or is it possible to
specify a source root and then use include to effectively specify
another?

Lastly, how does this fit in with morfs (module or files)? Would the
the source option feed into mofs?

[Ned Batchelder]

My plan (not yet fully implemented, so there may be snags) is that
source, include and omit would work together to specify the interesting
files. Source specifies a list of directories (or files), then include
is a pattern to match within those sources. Omit is used as a pattern
to further exclude files.

Pseudo-code:

def is_file_interesting(fpath):
if SOURCE:
for src in SOURCE:
if file_in_source(fpath, src):
break
else:
# File wasn't in any of our sources.
return False

if INCLUDE:
for inc in INCLUDE:
if file_matches(fpath, inc):
break
else:
# File didn't match any include pattern.
return False

if OMIT:
for om in OMIT:
if file_matches(fpath, om):
return False

So, you can't extend the source list with includes, includes are
evaluated within the sources. And for reporting, the sources will
effectively also clip your morfs, since there won't be any measurement
of files outside of the sources specified.

Does this sounds reasonable? As I looked at what people really wanted
to do when controlling coverage.py's attention, it seemed to me that it
was most natural to talk about code as directories or packages, and
"source" gives that direct control.

--Ned.

[Zooko O'Whielacronx]

On Wed, Jun 9, 2010 at 5:56 AM, Ned Batchelder <n...@nedbatchelder.com> wrote:
> My plan (not yet fully implemented, so there may be snags) is that source,
> include and omit would work together to specify the interesting files.
>  Source specifies a list of directories (or files), then include is a
> pattern to match within those sources.  Omit is used as a pattern to further
> exclude files.

I still don't see why I would want to use source when I already have
include and omit. I guess this is just because I always organize my
source code so that one or two inclusions or exclusions of a complete
subtree defines all the source files I care about. I.e., I never have
.py files sitting in my source tree that I don't want to have covered,
nor do I ever want to cover .py files that are not sitting in my
source tree.

Regards,

Zooko

[Ned Batchelder]

There are two reasons to add "source": 1) it lets you use package names
instead of file references, and 2) it doesn't require you to add * to
the directory to turn it into a file pattern. I think conceptually,
talking about trees of source code rooted at directories or packages
feels much more direct than providing a powerful but geeky feature like
file patterns.

--Ned.

[Zooko O'Whielacronx]

On Wed, Jun 9, 2010 at 3:21 PM, Ned Batchelder <n...@nedbatchelder.com> wrote:
> There are two reasons to add "source": 1) it lets you use package names
> instead of file references, and 2) it doesn't require you to add * to the
> directory to turn it into a file pattern.

Okay so it would obviate the need for line 246 of trialcoverage.py:

http://tahoe-lafs.org/trac/trialcoverage/browser/trialcoverage/trialcoverage.py?rev=36#L246

> think conceptually, talking
> about trees of source code rooted at directories or packages feels much more
> direct than providing a powerful but geeky feature like file patterns.

Sure, that's what I've wanted all along: just do coverage analysis of
the source code in this package.

Regards,

Zooko

[Ned Batchelder]

This is one of the things I find when digging into specific requests for
features: often they are masking the real request. Lots of people
wanted "omit files by pattern," and it turns out what they really wanted
was "don't trip over doctest files."

--Ned.

[memedough]

Hi,

I think the source option is good as it is most natural. I found when
I was playing that at first it felt awkward to have to add * at the
end for the pattern to work.

However I hope that you keep include and omit to whitelist / blacklist
patterns within the source. In fact due to the way our project is
(dis)organised I find it very useful to activate coverage and just
specify omit. So I think the source / include / omit that you
described allows very flexible specification of what to measure /
report.

:)

On Jun 11, 11:48 am, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 6/9/2010 5:30 PM, Zooko O'Whielacronx wrote:
>
> > On Wed, Jun 9, 2010 at 3:21 PM, Ned Batchelder<n...@nedbatchelder.com>  wrote:
>
> >> There are two reasons to add "source": 1) it lets you use package names
> >> instead of file references, and 2) it doesn't require you to add * to the
> >> directory to turn it into a file pattern.
>
> > Okay so it would obviate the need for line 246 of trialcoverage.py:
>

> >http://tahoe-lafs.org/trac/trialcoverage/browser/trialcoverage/trialc...

[Ned Batchelder]

I've just checked in support for "source", though not in the plugin
yet. I've kept include and omit, and they should all work together as
you describe.

--Ned.