[TIP] coverage.py input file

[Alfredo Deza]

On Thu, Aug 4, 2011 at 9:59 AM, Ned Batchelder <ned at nedbatchelder.com>wrote:

>  Programmatically, there's
> coverage.coverage(data_file="/path/to/datafile"), and in the configuration
> file, there's "[run] data_file=/path/to/datafile".  Is there another way you
> need to specify it?
>
> --Ned
>

It would be nice to have `data_file` to be exposed so I could pass it in via
the command line.

The problem with using the configuration file is that this is not something
static. Different projects in different directories have .coverage files
that
I am interested in.

I still think that better than a command line option would be that coverage
can crawl up until it finds a .coverage file to report on it (if there is
none in the
current directory). That way is automatic and you don't really need to be
thinking about where you are and where was coverage run from.

But that is a design decision and you will probably have your own thoughts
on this.

My case scenario still holds though: "I'm several directories in and want to
check the coverage report but it comes empty. So I have to go up until I am
in the same directory where the .coverage file is."

-Alfredo

>
>
> On 8/2/2011 10:18 AM, Alfredo Deza wrote:
>
> I was trying to look for an option in `coverage.py` that would accept a
> `.coverage` file as an input.
>
>  Usually `.coverage` is placed from wherever the command was run.
>
>  Is there such an option and I am just failing to find it? Or is this
> something that could be accepted as
> a feature request?
>
>  Probably something that makes coverage.py crawl back up in directories
> until it finds a `.coverage` file
> (a la git/hg) would make even more sense than an input file flag.
>
>  My reasoning for this is because a lot of times I find myself several
> directories deep into a project that has
> run coverage before but I can't get the proper report since there is no
> `.coverage` in the current directory.
>
>  Has anyone experienced something like this before? What are your
> workarounds (if any) ?
>
>  Thanks!
>
>  -Alfredo
>
>
> _______________________________________________
> testing-in-python mailing listtesting-in-python at lists.idyll.orghttp://lists.idyll.org/listinfo/testing-in-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20110804/614ba7fb/attachment.htm>