Probably, yeah. Though unless it's Real Python™ code, and can do lots of shenanigans, I don't see how it's more flexible. And all those shenanigans mean :'( in the same ways as setup.py. And if it's not Real Python™ and just a python-like declarative syntax, then why not just add the features to requirements.txt and the command-line, and maintain that parity?

Dependency groups don't really mean an advantage to me. E.g. with pip-tools, on the code I work on, we've got 3 requirements*.txt files. One (requirements.txt) for prod, and ones for test/dev/any additional scopes you may want. Then you `-r requirements.txt` in requirements-dev.in (and -test), and you're guaranteed to maintain the same versions as production when resolving requirements-dev.txt, or have conflicts if something dev adds prevents that from working. In CI / build / etc you just install the single file that's relevant to you.

Bundling groups into the file would be nice for not being able to make mistakes (our approach above requires you to compile things in order, for example), but that would have to weigh pretty heavily against breaking backwards compatibility and a very-simple DSL that already exists.