Warning "Already imported a file that will be measured" when using namespace packages

[remram44]

Describe the bug

When using namespace packages (declared through setup.py as namespace_packages=[...]) coverage shows warnings "Already imported a file that will be measured" for the __init__.py files.

setup(
    # ...
    packages=['testcov'],
    namespace_packages=['testcov'],
)

Those files simply contain the declare_namespace() call:

try:  # pragma: no cover
    __import__('pkg_resources').declare_namespace(__name__)
except ImportError:  # pragma: no cover
    from pkgutil import extend_path
    __path__ = extend_path(__path__, __name__)

To Reproduce How can we reproduce the problem? Please be specific.

1. What version of Python are you using? 3.6
2. What version of coverage.py are you using? 5.0
3. What versions of what packages do you have installed? Only coverage 5.0
4. What code are you running? Give us a specific commit of a specific repo that we can check out. I made a minimal example here: https://github.com/remram44/coverage-bug-888 Warning shows up in Travis: https://travis-ci.org/remram44/coverage-bug-888/builds/625849023#L460
5. What commands did you run? coverage run --source=/tmp/testcov/app,/tmp/testcov/plugin app/testcov/main.py (see run.sh in repo)

Expected behavior

I didn't expect to see a warning.

Additional context This problem was uncovered in ReproZip: https://travis-ci.org/VIDA-NYU/reprozip/jobs/625416082#L4117

Documentation on namespace packages with pkg_resources: https://packaging.python.org/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages

[nedbat]

This is fixed in commit 1a6844ae.

[nedbat]

This is now released as part of coverage 6.1.1.

[jmpatri1]

I am still getting already-imported errors with namespace packages in coverage 6.3.2.

Looking at the fix provided in commit 1a6844a I see the module path array len is checked for >1, however when I insert some debug statements into that file my module paths are always an array of length 1, failing the test and producing the warning. Changing the check to >0 does eliminate the warning, although I am unfamiliar with the module attributes and if this is a valid change.