Over the years, as I have used python's entry-point feature extensively, I have
often found dependency issues that were not captured by binary packages.  One
bug report that I made that is currently still open is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126289 which reports a
dependency issue for python3-limits.  Running this simple script:


import pkg_resources

for dist in pkg_resources.working_set:
    try:
        pkg_resources.require(dist.project_name)
    except Exception as exc:
        print(f"{exc.__class__.__name__}:\t{exc}")


one can see that, among the packages installed on my computer, there are 23
dependency issues:


DistributionNotFound:   The 'debconf' distribution was not found and is
required by apt-listchanges
DistributionNotFound:   The 'tzdata; python_version >= "3.9"' distribution was
not found and is required by arrow
ContextualVersionConflict:      (agate-dbf 0.2.2 (/usr/lib/python3/dist-
packages), Requirement.parse('agate-dbf>=0.2.3'), {'csvkit'})
ContextualVersionConflict:      (stone 3.3.9 (/usr/lib/python3/dist-packages),
Requirement.parse('stone<3.3.3,>=2'), {'dropbox'})
ContextualVersionConflict:      (hpack 4.0.0 (/usr/lib/python3/dist-packages),
Requirement.parse('hpack<5,>=4.1'), {'h2'})
DistributionNotFound:   The 'hf-xet<2.0.0,>=1.2.0' distribution was not found
and is required by huggingface-hub
ContextualVersionConflict:      (packaging 26.2 (/usr/lib/python3/dist-
packages), Requirement.parse('packaging<25,>=21'), {'limits'})
ContextualVersionConflict:      (protobuf 4.21.12 (/usr/lib/python3/dist-
packages), Requirement.parse('protobuf<7,>=5.26'), {'nitrokey'})
ContextualVersionConflict:      (protobuf 4.21.12 (/usr/lib/python3/dist-
packages), Requirement.parse('protobuf<7,>=5.26'), {'nitrokey'})
ContextualVersionConflict:      (poetry-core 2.3.1 (/usr/lib/python3/dist-
packages), Requirement.parse('poetry-core==2.3.2'), {'poetry'})
ContextualVersionConflict:      (cachetools 7.0.1 (/usr/lib/python3/dist-
packages), Requirement.parse('cachetools>=7.0.3'), {'tox'})
DistributionNotFound:   The 'django-stubs<5.3,>=4.2' distribution was not found
and is required by types-channels
DistributionNotFound:   The 'Flask>=2.3.2' distribution was not found and is
required by types-click-web
DistributionNotFound:   The 'django-stubs' distribution was not found and is
required by types-django-filter
DistributionNotFound:   The 'django-stubs' distribution was not found and is
required by types-django-import-export
DistributionNotFound:   The 'Flask>=2.0.0' distribution was not found and is
required by types-flask-cors
DistributionNotFound:   The 'Flask>=2.0.0' distribution was not found and is
required by types-flask-migrate
DistributionNotFound:   The 'Flask>=0.9' distribution was not found and is
required by types-flask-socketio
DistributionNotFound:   The 'pyproj' distribution was not found and is required
by types-geopandas
DistributionNotFound:   The 'pandas-stubs' distribution was not found and is
required by types-seaborn
DistributionNotFound:   The 'ua-parser-builtins' distribution was not found and
is required by ua-parser
DistributionNotFound:   The 'ua-parser-builtins' distribution was not found and
is required by ua-parser
ContextualVersionConflict:      (sphinx 9.1.0 (/usr/lib/python3/dist-packages),
Requirement.parse('sphinx<8.3,>=8.2'), {'zzzeeksphinx'})


Shouldn't dh-python find these dependencies automatically?  Or is it too
complex to automatically derive package dependencies from distribution setup
files?  In the case of the bug reports I made, the dependencies were usually
specified in pyproject.toml but apparently not analyzed by dh-python's scripts
(I must confess I only know a bare minimum about dh-python).

I hope this is useful.  If this is not an issue, please feel free to close this
bug.

Hi Johnny (2026.07.24_11:44:39_+0000)

The good news is that this mechanism is heavily deprecated upstream. So
it shouldn't be an issue much longer.

https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/#using-package-metadata

We have encouraged people to patch Python dependencies where possible,
so that we don't run into this.

I have no desire to solve this problem in dh-python, especially as
pkg_resources is being retired.

Stefano

Hello,

Thank you for the feedback.

The issue I reported is not related to pkg_resources, which has indeed
deprecated for a few years.  I used pkg_resources because the code was
short and showed version conflicts quickly.

The modern alternative to pkg_resources is importlib.metadata, which can
also show issues.  For example the quickly-written following script will
list version conflicts:


#!/usr/bin/python3

import importlib.metadata

from packaging.requirements import Requirement

for d in importlib.metadata.distributions():
     if not d.name:
         continue
     requires = importlib.metadata.requires(d.name)
     requirements = [Requirement(req) for req in requires] if requires
else []

     for r in requirements:
         try:
             v = importlib.metadata.distribution(r.name).version
         except importlib.metadata.PackageNotFoundError:
             # print(f"{d.name} requires {r.name}, which is not installed")
             pass
         else:
             if not r.specifier.contains(v):
                 print(f"{d.name} requires {r.name} {r.specifier} but
{v} is installed")


On my computer, this will print for example:

   h2 requires hpack <5,>=4.1 but 4.0.0 is installed

One can indeed check that python3-hpack 4.0.0-4 is installed in testing,
and that h2 requires a more recent version:

$ grep Requires-Dist
/usr/lib/python3/dist-packages/h2-4.3.0.dist-info/METADATA
Requires-Dist: hyperframe<7,>=6.1
Requires-Dist: hpack<5,>=4.1

The version conflict exists, pkg_resources was just a quick way among
others to list them.

The version conflicts may be harmless, for example packages that require
a different version of sphinx.  But in the case of h2, one would think
that, if the maintainer took the time to specify that the version of
hpack must be greater than 4.1, it means h2 wouldn't work normally with
version 4.0.

In other cases, the required version even has a different major number
than the installed version, for example:

   zstandard requires cffi ~=1.17 but 2.0.0 is installed
   APScheduler requires protobuf <=3.21.0 but 4.21.12 is installed
   eyed3 requires Pillow <10.0.0,>=8.0.1 but 12.3.0 is installed
   arrow requires simplejson ==3.* but 4.1.1 is installed
   uvloop requires pyOpenSSL ~=25.3.0 but 26.2.0 is installed

and many more.  This may be harmless if the project is not using
semantic versioning, but if it does, it means that a package is
expecting a different API/ABI than what the installed dependency offers!

Again, this may not be a big deal, but I'd personally be quite scared if
I found such version conflicts in my own projects 🙂

If you still think this is not an issue, you may close this bug now.  I
thought I ought to report it.

Thanks!