Advice regarding Improved UX for group dependencies.

[ammargit93]

This discussion is related to the proposal in #8164, where adding a dedicated description field for dependency groups in pyproject.toml was suggested.

I wanted to ask whether introducing an additional metadata block per group is the preferred direction, or if it risks increasing verbosity in pyproject.toml, particularly for projects with multiple dependency groups.

As an alternative, would it make sense to avoid extending the configuration format and instead focus on improving CLI discoverability? For example:

• displaying existing dependency groups via a CLI flag (e.g. poetry show --groups), and

• optionally capturing group descriptions interactively during group creation and displaying them only in CLI output, without persisting them in pyproject.toml.

I’m interested in maintainer feedback on whether keeping group descriptions out of the configuration file aligns better with Poetry’s design goals, or if explicit TOML metadata is considered acceptable in this case.

[radoering]

• displaying existing dependency groups via a CLI flag (e.g. poetry show --groups), and

This makes sense to me.

• optionally capturing group descriptions interactively during group creation and displaying them only in CLI output, without persisting them in pyproject.toml.

This does not make sense to me. If we want to introduce a description, it should be persistent. I do not care much about introducing a description.

Before implementing something, we should define how the output of poetry show --groups (or any other command) should look like. For example, I do not think that poetry list --groups (as proposed in #8164) makes sense because list is for displaying commands. However, the output of poetry show --groups could look like either proposal in #8164.

@Secrus Do you have an opinion on a description for groups and what the UI for displaying groups should look like?

[Secrus]

I don't really understand the reason for listing groups in the first place. We don't expose commands to print metadata from pyproject.toml, so why should groups be different? If we actually want to print available groups, I would rather see more centralized poetry metadata command that would serve as an entrypoint for various metadata queries. Any other way screams inconsistency.

As to descriptions for groups: that is not part of dependency-groups spec AFAIK, so I don't why we would be in business of introducing special additions to the standard. Looking back, creating our own ways around standard, usually bit us in the lower backs.

[radoering]

I don't really understand the reason for listing groups in the first place. We don't expose commands to print metadata from pyproject.toml, so why should groups be different?

Good point. What is the advantage of a command that lists groups compared to just looking into pyproject.toml?