Implicit namespace submodules not discovered

[adamchainz]

Describe the bug

If an implicit namespace package (directory without __init__.py) exists within a source module and is not imported, coverage won't discover it or report it as uncovered.

I discovered this on Django project where an app had an idiomatic management.commands submodule without intermediate __init__.py files. This had two levels of implicit namespace packages, but it also happens with just one (what would be just management).

To Reproduce

Worked example:

$ coverage --version
Coverage.py, version 5.2.1 with C extension
Full documentation is at https://coverage.readthedocs.io
$ python --version
Python 3.8.3
$ tree example
example
├── management
│   └── submodule2.py
└── submodule.py

1 directory, 2 files
$ cat example/submodule.py
x = 1
$ cat example/management/submodule2.py
y = 2
$ cat test.py
import example.submodule
$ coverage erase && coverage run --source example -m test && coverage report
Name                   Stmts   Miss  Cover
------------------------------------------
example/submodule.py       1      0   100%

Expected behavior

I'd expect example/management/submodule2.py to be discovered as uncovered. Adding an __init__.py to management makes coverage discover it:

$ touch example/management/__init__.py
$ coverage erase && coverage run --source example -m test && coverage report
Name                               Stmts   Miss  Cover
------------------------------------------------------
example/management/__init__.py         0      0   100%
example/management/submodule2.py       1      1     0%
example/submodule.py                   1      0   100%
------------------------------------------------------
TOTAL                                  2      1    50%

Additional context

Implicit namespace packages "just work" with Python 3, and many new developers create them on purpose or accidentally.

Django itself has moved to, and then back from, implicit namespace packages for management commands: https://groups.google.com/g/django-developers/c/GVHMH2ciAnk/m/7RzvMIzyAQAJ . So there are at least some users who believe "__init__.py files are no longer needed".

[nedbat]

Coverage.py tries to guess what files in the tree might have been importable in order to tell you what wasn't imported. We don't want it to walk into a bin directory and find .py files and say they weren't imported. So I'm not sure what to do here.

Would it be acceptable to have to enable implicit package spidering with a config setting? Should we insist that you say in the config file what the implicit packages are?

[adamchainz]

Would it be acceptable to have to enable implicit package spidering with a config setting?

For me, yes, but I fear it would only be discovered by a few. Why not go the other way and require explicit omit entries for directories? If example/bin/someting.py exists, it probably is importable as example.bin.something, even if the author didn't intend.

Should we insist that you say in the config file what the implicit packages are?

That wouldn't help in the situation I ran into - knowing you had to declare the module to coverage would be the same as knowing it'd be better to create the __init__.py files.

[graingert]

could use something like this: https://github.com/pypa/setuptools/blob/edcf84faaf17e87e6e38796dd24f66d9236bf87c/setuptools/__init__.py#L110-L119

[graingert]

[coverage:run]
find_namespace_packages = True
source = example

[romesco]

If this isn't likely to be supported anytime soon, does anyone have an appropriate work around? I'm also stuck on this.

[graingert]

@romesco I use https://pypi.org/project/flake8-no-pep420/ as a workaround

[romesco]

Nice! Thanks @graingert! It looks like @adamchainz (OP) got tired of the problem and created this shortly after filing the issue 😆 .

For the record, I ended up adding both the dir above the namespace dir as well as the namespace dir itself to the tool.coverage.run source argument in my pyproject.toml and it seemed to end up working.

Here is the rough structure:

├── package-name
│   ├── namespace_package
│   │   └── subpackage
│   │       ├── __init__.py
│   │       └── module_x.py
│   └── tests
│       ├── __init__.py
│       └── test_module_x.py
└── pyproject.toml

In total my config was:

# pyproject.toml
...
[tool.coverage.paths]
source = ["package-name"]

[tool.coverage.run]
branch = true
source = [
    "package-name",
    "package-name/namespace_package"
]
omit = ["*site-packages*", "*tests*"]
...

Hope this helps someone!

[pawamoy]

Thanks @romesco! Your workaround well, worked 😄
Here's my diff:

 [coverage:run]
 branch = true
 parallel = true
 source =
-  src/
+  src/mkdocstrings/handlers/
   tests/

I had to specify the directory down to the first one which contains explicit packages:

% tree src 
src
└── mkdocstrings
    └── handlers
        └── python
            ├── __init__.py
            ├── collector.py
            └── renderer.py

EDIT: oops, actually coveragepy now reports renderer.py and collector.py, but with 0% coverage... still work needed 😕

[pawamoy]

Is there a way to see the exact file paths coveragepy finds and measures?

[matpen]

I just got surprised by this, too.

Could it be a solution to support the sourcedir/** syntax in the --source CLI option? I am noticing that this does not work, but it could be made to mean "add and all subfolders to the source", regardless of presence of __init__.py files.

Note that this already works, i.e. using --source=sourcedir,sourcedir/subfolder correctly scans all files in sourcedir and sourcedir/subfolder.