Hello,
I am currently packaging silx 3.0.1 for Debian and I am trying to rely on the
dependencies declared in pyproject.toml to populate the test/autopkgtest
dependencies.
The project uses nested optional dependency groups. In pyproject.toml, the
relevant part looks like this:
[project.optional-dependencies]
opencl = [
'pyopencl',
'Mako',
]
full_no_qt = [
'silx[opencl]',
'qtconsole',
'matplotlib >= 3.6',
'PyOpenGL',
'python-dateutil',
'scipy',
'pooch',
'Pillow',
'pint',
'hdf5plugin',
'qtawesome',
]
full = [
'silx[full_no_qt]',
'PySide6 >= 6.5',
]
h5pyd = [
'h5pyd >= 0.20.0'
]
test = [
'silx[full,h5pyd]',
'bitshuffle',
'pytest',
'pytest-xvfb',
'pytest-cov',
'pytest-mock',
'pytest-httpserver',
]
My understanding was that selecting all optional dependencies, or selecting the
test extra, should recursively include the dependencies from the nested extras
as well. In particular:
test -> full -> full_no_qt -> qtawesome, PyOpenGL, ...
However, during autopkgtest, some modules that should come from nested extras
are missing. For example, the test suite fails during collection with:
/usr/lib/python3/dist-packages/silx/gui/plot/tools/_PlotOptionButton.py:5: in
<module>
import qtawesome
E ModuleNotFoundError: No module named 'qtawesome'
There are also similar failures for modules such as OpenGL.
This makes me suspect that the dependency extraction/resolution only handles
the first level of optional dependencies, but does not recursively expand
nested extras such as silx[test] -> silx[full] -> silx[full_no_qt].
Could you please clarify what the expected behaviour is here?
More specifically:
1. Should dh_python3 recursively resolve nested optional dependency groups
from pyproject.toml?
2. If yes, is this a bug in the current handling of optional dependencies?
3. If not, what is the recommended Debian packaging approach for this case?
4. Is there a way to ask dh_python3 to expand all nested optional dependency
groups when generating test/autopkgtest dependencies?
For now, I can work around the issue by manually adding the missing
dependencies to debian/control or debian/tests/control, but I would like to
understand whether this is the intended approach or whether the nested extras
should be resolved automatically.
Thanks a lot for your help.
