Hey.

It would be nice if dh-python could automatically the optional
dependencies from the project.optional-dependencies section in
pyproject.toml (if that is used for building) and use it for Suggests
and or Recommeds:.

Now the problem is obviously that pyproject.toml doesn't differ
between Suggest/Recommends and so dh_python can't know which of the
two to use.
Maybe one could do the following (for the packages that would result
from that section:
- any dependency that is already explicitly listed in
[Pre-]Depends:/Recommends:/Suggests: is ignored (assuming that the
maintainer wants it exactly where he placed it)
- for the remaining ones one could somehow (e.g. via a dh_python)
option specify which section (primarily Recommends or Suggests, but
perhaps even [Pre-]Depends) should be used (like a default


A possible idea for the long term future might even be, to allow
specifying special comments in pyproject.toml, which could be used by
Debian-friendly upstreams to really encode in pyproject.toml what
dh_python should do with an optional dependency, e.g. something like:

[project.optional-dependencies]
foo = ["requests"]
#dh-python-section-hint=recommends:
bar = ["httpx"]
#dh-python-section-hint=suggests:
baz = ["numpy"]

In the above example, there would be no hint for requests, a
Recommends: hint for httpx, and a Suggest: hint for numpy and all
others that possibly follow (i.e. always up to the next one).

One could even allow for more fine grained overrides, like:
[project.optional-dependencies]
foo = [
          "requests",  #:dh-python-section-hint=suggests
          "httpx",  #:dh-python-section-hint=recommends
          "numpy"  #:dh-python-section-hint=suggests
         ]

of curse one would need to document which exact formats dh_python can parse.

Thanks,
Philippe.

Hi Philippe

I assume that you've already seen the --recommends-section=SECTION and
--suggests-section=SECTION options for dh_python3?

I don't think filling pyproject.toml with hints would be a nice path
forwards - upstreams don't really want to fill their file with
Debian-specific hints like this, and so few would do so that having a
separate mechanism would be needed in any case.

If setting these options via an override in d/rules is not wanted (for
declarative packaging), either a separate file in debian/ or an
environment variable set in d/rules is the normal approach.

An alternative option for this case could be to make substvars for each
section that can be put into the Recommends or Suggests, something like
${python3:optional-dependencies:dev}
${python3:optional-dependencies:foo} etc.

cheers
Stuart

Hey again.

Indeed I did, but TBH I didn't quite realize how to use it and found
no documentation... and even the almighty AI meant it was merely
useful if there a requirements.txt (or something like that) was used
rather than pyproject.toml.

Well as said, that particular part was just an idea what one might do
in the future.

Is there any example on how to use them?

That seems to go in the right direction, but has the problem that,
AFAIU your idea, one would still need to manually edit control for
every new optional dependency?

Would it be possible to have something like the above, but just
${python3:optional-dependencies} and that this contains "simply" all
the optional dependencies that haven't been explicitly specified by
the maintainer in control?
I mean that would probably again fail to work if one builds multiple
binary packages, but for many simple cases where one has anyway only
one binary, it could work.

Would a Would a ${python3:optional-dependencies:dev} also contain
version information? Cause then it would actually still be better than
just manually naming the dependency in control.

Maybe having both, would be nice then.

Thanks,
Philippe.

Hey.

So I think I found out how to use --suggests-section=, namely via e.g.:

override_dh_python3:
        dh_python3 --suggests-section=foo --suggests-section=bar

with foo and bar being the names I've used above in my pyproject.toml
[project.optional-dependencies] section.
Looking at the code, I'd say dh_python rather reads them from
requirements.txt (which is however somehow generated from
pyproject.toml).

That's already quite nice... could it be improved to allow a wildcard
like =* to simply take all section? IIRC the syntax of these names
like "foo" are anyway restricted by Python (and don't allow *).

It would of course still be better if any dependency that has been
explicitly given in debian/control is excluded... but even the
wildcard would be better than "nothing".

It would be nice if this could be documented (I mean *what* the
sections are...).

Also, am I doing the override correctly? Or do I need to set further
options to get the behavior of the "pristine" dh_python?

Thanks,
Philippe

PS: Why is the --with python3 still needed, if dh-python has anyway
"only" dh_python3?

Hi Philippe (2026.06.01_23:23:00_+0000)

Yes, that's correct.

dh_python does not read requirements.txt. I think you're confusing it
with foo.egg-info/requires.txt which is a different thing.

Sure... but I don't think I've ever seen a request for something like
that before. It sounds like you may be the only package that would use
it.

That's not an issue. dh_genchanges merges duplicates.

Looks good to me.

To tell debhelper to run dh_python3. This requirement goes away in
compat 14.

Stefano

I think it would be useful to kinda automatically "catch" any newly
added optional dependencies?!
If a maintainer doesn't check the upstream project for any new ones,
adding them via --suggests* /etc. might simply be overlooked.
So I figured it might be good to kinda automatically add any leftovers
as Suggests:.
added to suggests via a ${python3:Suggests}?
Cause I think we don't wanna have "vertical" duplicates either.

Thanks :-)

Ah I see :-)

Thanks,
Philippe