Describe the bug
We build and test in directories that contain the + character (as a separator in a version string). Using a .coveragerc file in such a directory that contains an omit specification that does not begin with a * or ? wildcard fails.
To Reproduce
How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:
What version of Python are you using?
3.10
What version of coverage.py shows the problem? The output of coverage debug sys is helpful.
7.0.0. 6.5.0 is fine.
What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix.
$ mkdir cov+test cov+test/tests
$ cd cov+test
$ echo -e "[run]\nomit = x/*" > .coveragerc
$ echo -e "def test_foo():\n assert 4 == 4" > tests/test_foo.py
$ coverage run tests/test_foo.py
File pattern can't include '+'
$ cd ..
$ mv cov+test covtest
$ cd covtest
$ coverage run tests/test_foo.py
$
What commands did you run?
See above.
Expected behavior
See above.
Additional context
I'm not sure why a complex custom glob-to-regexp translator was used instead of glob, but I suggest that regexp metacharacters be quoted instead of causing failures, as they're quite legal and not infrequently used in pathnames. Perhaps leaving out files.py:328 would be sufficient.
Describe the bug We build and test in directories that contain the
+
character (as a separator in a version string). Using a.coveragerc
file in such a directory that contains anomit
specification that does not begin with a*
or?
wildcard fails.To Reproduce How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:
coverage debug sys
is helpful. 7.0.0. 6.5.0 is fine.pip freeze
is helpful.Expected behavior See above.
Additional context I'm not sure why a complex custom glob-to-regexp translator was used instead of
glob
, but I suggest that regexp metacharacters be quoted instead of causing failures, as they're quite legal and not infrequently used in pathnames. Perhaps leaving out files.py:328 would be sufficient.