A way to pre-configure a map of package names to module names

[akeeman]

PR Checklist

• A description of the changes is added to the description of this PR.
• If there is a related issue, make sure it is linked to this PR.
• If you've fixed a bug or added code that should be tested, add tests!
• Documentation in docs is updated

Description of changes

Adding a pre-configured map between package names and module names, so not installed modules don't produce errors when a package name doesn't auto-convert to the module name. E.g. package name foo-python is translated to module foo_python, but it's actually called foo.
Fixes #332

[tool.deptry.package_module_name_map]
foo-python = [
    "foo",
]

Before adding tests & docs, let's see if this is an acceptable problem & solution direction.

[codecov]

Codecov Report

Merging #333 (818e45a) into main (2f39fb5) will decrease coverage by 0.8%.
The diff coverage is 83.0%.

@@           Coverage Diff           @@
##            main    #333     +/-   ##
=======================================
- Coverage   91.8%   91.1%   -0.8%     
=======================================
  Files         29      29             
  Lines        955     991     +36     
  Branches     201     212     +11     
=======================================
+ Hits         877     903     +26     
- Misses        50      56      +6     
- Partials      28      32      +4     

Impacted Files	Coverage Δ
deptry/dependency_getter/pep_621.py	88.3% <60.0%> (-4.2%)	⬇️
deptry/dependency_getter/base.py	80.7% <66.6%> (-2.6%)	⬇️
deptry/dependency_getter/poetry.py	95.4% <71.4%> (-4.6%)	⬇️
deptry/core.py	92.3% <83.3%> (-0.9%)	⬇️
deptry/dependency.py	88.7% <85.7%> (-2.6%)	⬇️
deptry/cli.py	92.7% <90.9%> (-0.9%)	⬇️
deptry/dependency_getter/pdm.py	92.3% <100.0%> (ø)
deptry/dependency_getter/requirements_txt.py	96.2% <100.0%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[fpgmaas]

Thanks for opening the PR! I think the added functionality looks good. I was not able yet to test is locally successfully. Do you have a good example package that can be used for testing? I recall encountering this issue in the past, but I do not recall with which package. For now, I tried cheating a bit and just switching

[tool.deptry.package_module_name_map]
click = [
    "tomli",
]
tomli = [
    "click",
]

But because we also still look for metadata, this results in:

--- MODULE ---
name: tomli
standard_library: False
local_module: False
package: tomli
top_levels: ['click', 'tomli']
dev_top_levels: []
is_dependency: True
is_dev_dependency: False

so my hacky local test that does not really work :)

If you would be so kind to add unit tests and documentation, I would be happy to review and merge!

[akeeman]

Good examples are packages that have a prefix python- or postfix -python, like python-dotenv, that installes top level module dotenv.

[akeeman]

But because we also still look for metadata

I think it's OK to look for metedata for other uses. As far as I can see the only use case is the 'publicly' available property found. If a mapping is available for the package, no second metadata lookup is performed. The mapping is prioritized over both the lookup methods.

[fpgmaas]

A small formatting issue in the CI/CD, otherwise; looks good to me! I really appreciate you taking the time to add this feature!

[akeeman]

There you go! Pre-commit found some more stuff.