Support submodule-level resolution for namespace packages (PEP 420)

[jamesbraza]

Is your feature request related to a problem? Please describe.

Let's say I have some namespace packages pkg-a and pkg-b like so:

.
├── pkg-a
│   ├── src
│   │   └── pkg
│   │       └── a.py
│   └── tests
│       └── test_pkg_a.py
└── pkg-b
    ├── src
    │   └── pkg
    │       └── b.py
    └── tests
        └── test_pkg_b.py

These packages, when installed, get stitched together in the virtual env like so:

└── site-packages
    └── pkg
        ├── a.py
        └── b.py

Unfortunately deptry (as of version 0.25.1) cannot detect that a.py comes from pkg-a and b.py comes from pkg-b. All imports from the shared namespace are collapsed to the top-level name, so any single sibling dependency satisfies all of them.

In other words, deptry cannot detect missing dependencies when multiple distributions share a top-level module name via native namespace packages (PEP 420).

Describe the solution you would like

deptry understanding that:

• If a package just uses pkg.a, it needs to have pkg-a (and that pkg-b is not relevant)
• If a package just uses pkg.b, it needs to have pkg-b (and that pkg-a is not relevant)

[mdaubie]

+1, real pain point for Azure and Google SDKs, which use namespaces and have dozens of packages each.