Properly Config Inclusion/Exclusions about coveralls-python HOT 8 CLOSED

I may have answered my own question by using this boilerplate https://gist.github.com/ssokolow/5496286

from coveralls-python.

I'm glad you've figured out how to work around this bug. I've not tested nose or py.test coverage plugins, I guess they behave slightly differently than simple coverage.py, that's why the difference. I'll keep this open until I find decent solution or document this workaround in docs.

from coveralls-python.

Could you confirm that how coveralls works is to pick up the generated .coverage report and parse it into readable report?

from coveralls-python.

Nope, it generates custom report based on .coverage data + source files.

from coveralls-python.

Ah I see. Does coveralls fully respect .coveragerc config file? If not then that might explain the behavior.

from coveralls-python.

Should coveralls know anything about .coveragerc? I think it's enough coverage.py itself takes this file into account when generating .coverage file. However, the [report] section is ignored most definatley, as I'm using custom reported... I'll look inot that, thnx.

from coveralls-python.

I believe that by parsing .coveragerc, especially by looking at both [run] and [report] sections of inclusion/exclusion patterns, coveralls would save a lot of time going through the unintended source files, hence improves on submission size/time and makes the overall experience as compatible to local coverage.py behavior as possible without digging too much into py.test and/or nose coverage plugin's behavior.

from coveralls-python.

Turns out, I was not correct in my previous comments. Coveralls does honor .coveragerc config. It's nose, which does not (at least, for source options). I've documented your workaround, thnx.

from coveralls-python.