Imports with package names different from module names are wrongly reported as missing instead of transitive

[Willa1228]

Environment

• deptry version: 0.16.1
• Python version: 3.11
• Operating system (e.g. Ubuntu 22.04, Windows 11): Mac OS 14.0

Describe the issue

I have a project which has django-cms in its requirements.txt, and I import those packages depend on django-cms like django-classy-tags, django-formtools... those should be detected as a transitive dependency, but it seems deptry can't recognize those with a - packages's name, so it turns out detected as a missing dependency.

Minimal way to reproduce the issue

1. Have a new project with django-cms in the requirements, and install in a conda environment
2. In project
   import classytags
   from formtools.wizard.views import WizardView
   import sekizai
   from treebeard.mp_tree import MP_Node
   from packaging import version
3. python -m deptry .

those with - will be detected as DEP001 incorrectly, but without dash's package can be detected as transitive successfully.

[mkniewallner]

Thanks for the report, the issue is not exactly about having - (we even have a fallback mechanism for this specific case since it's so common). It actually happens whenever the package name and the module name are different. For instance, it's also possible to reproduce with the following requirements.txt:

itchiodl==2.3.0

and the following Python file:

import bs4
import itchiodl

(itchiodl depends on beautifulsoup4, which is imported as bs4)

Then if we run deptry .:

$ deptry .
Scanning 1 file...

foo.py:1:8: DEP001 'bs4' imported but missing from the dependency definitions
Found 1 dependency issue.

The issue is that we currently try to guess the Python module names for each package by only taking into account the direct dependencies (defined for instance in requirements.txt, or in pyproject.toml).

In order to handle this case properly, we'd need to be able to apply the reverse logic, i.e. after we parse all imports in the codebase, we guess the Python package from the module names. We'll need to check if it's possible to do easily without breaking the current logic.