Dealing with dependencies with hierarchical name convention (question)

[threonate]

In our framework, we developed a number of Python packages with a specific hierarchical name convention

a.b.c
a.b.d
a.f.z

etc.

In a package I want to check with deptry, these packages are imported as any other packages

import a.b.c
from a.b.d import func

but deptry complains about it:

DEP001 'a' imported but missing from the dependency definitions
DEP001 'a' imported but missing from the dependency definitions

That is true for a venv without dependencies of a package at hand installed.

In a venv with all dependencies installed, deptry scan is successful. However, if I add another package from the same namespace, say a.y.z and install in the venv but have no imports of it in the source code, deptry issues no complains about it.

Can it be sorted out with deptry configuration?

[namruf15]

I'd like to bump this issue as we're also facing the same in our project. Please give a shout if you could plan such improvement for deptry as it is quite useful for our sanity pipelines and we'd like to use it further with support for hierarchical namespaces.

[ericyuegu]

+1, it would be tremendously useful to be able to distinguish whether namespace packages have been properly declared as dependencies. So, if someone writes from a.y.z import func without adding a.y.z to their dependencies in pyproject.toml, deptry should complain.

[JPK64]

We're having the same issue with llama-index in our application.

We support multiple LLM providers using the packages llama-index-llms-azure-openai, llama-index-llms-gemini and llama-index-llms-ollama, installing the relevant python modules into llama_index.llms.azure_openai, llama_index.llms.gemini and llama_index.llms.ollama respectively.

All works well as long as you have all of these packages installed. As these are optional dependencies because you typically only need the packages for one LLM provider, package module name resolution fails for all packages not installed. Adding a package_module_name_map like this

[tool.deptry.package_module_name_map]
llama-index-llms-azure-openai = "llama_index.llms.azure_openai"
llama-index-llms-gemini = "llama_index.llms.gemini"
llama-index-llms-ollama = "llama_index.llms.ollama"

does not work either. Maybe implementing it so this map can also work with namespace packages instead of only top-level modules would be a solution to this problem?

For the time being, we do not have any other option than ignoring the rules for these particular dependencies, which is not ideal.