Check if the given requirements are all satisfied.
[...]
[Returns:] All the requirements in reqs satisfied or not.
But in reality, it only checks transitive ("nested") dependencies if they're part of a top-level extra or its extras, recursively.
To reproduce
To convince yourself that this is the case, you can:
Install typer-slim[standard]==0.12.5.
This depends on rich for the standard extra, while rich in turn depends on Pygments unconditionally.
Uninstall Pygments manually with Pip, leaving rich itself installed but with broken dependencies.
Notice that check_reqs("typer-slim[standard]") still returns True.
Optional sanity check: Uninstall rich, which will cause check_reqs("typer-slim[standard]") to correctly return False (because its direct dependent is the standard extra of typer-slim).
Comparison to "reference" library
This is different from the behavior of e.g. pkg_resources.require, which checks all dependencies recursively whether they're part of an extra or not.
So IMO either a) the documentation of check_reqs should be updated to reflect the fact it only looks at packages that are dependencies of a top-level extra (or extras below that, recursively) or b) this should be fixed to behave the same as pkg_resources.require.
The problem
The documentation of
check_reqssays:But in reality, it only checks transitive ("nested") dependencies if they're part of a top-level extra or its extras, recursively.
To reproduce
To convince yourself that this is the case, you can:
typer-slim[standard]==0.12.5.richfor thestandardextra, whilerichin turn depends onPygmentsunconditionally.Pygmentsmanually with Pip, leavingrichitself installed but with broken dependencies.check_reqs("typer-slim[standard]")still returnsTrue.rich, which will causecheck_reqs("typer-slim[standard]")to correctly returnFalse(because its direct dependent is thestandardextra oftyper-slim).Comparison to "reference" library
This is different from the behavior of e.g.
pkg_resources.require, which checks all dependencies recursively whether they're part of an extra or not.Cause in the code
The code section that causes this to happen: https://github.com/HansBug/hbutils/blob/927b0757449a781ce8e30132f26b06089a24cd71/hbutils/system/python/package.py#L184-L192 Only extras are iterated over to determine whether a child dependency should be processed.
What I think should happen
So IMO either a) the documentation of
check_reqsshould be updated to reflect the fact it only looks at packages that are dependencies of a top-level extra (or extras below that, recursively) or b) this should be fixed to behave the same aspkg_resources.require.Thoughts?