Why can't setuptools indefinitely support dash aliases like long-description vs long_description?

[jackklika]

I couldn't find any specific answer for this when looking around. But I was wondering, in light of the future possibility of breaking builds using long-description, why this can't just be treated as an alias.

The only answer I have seen so far is for "simplicity in setuptools code", but are there any other specific reasons that this cannot just be a perpetual alias?

[fixermark]

Concur with this suggestion.

There are so_many standards-for howTokens MustBe SHAPED_TO make a parser happy. For N different configuration schema, as an end-user, I have to keep N different rules in my brain somewhere.

Being permissive here is actually a kindness to end-users at what should be only the cost of having to run the keys through a single canonicalizer in the code (which is also a good place to put validation logic to confirm that, for example, unrecognized Unicode characters aren't being used).

There is a counter-argument leaning on the Zen of Python: "There should be one-- and preferably only one --obvious way to do it." I usually concur with this advice. But given how broadly the use of both hyphens and underscores has spread in config keys ("description-file" alone shows up to a cursory search of GitHub in over 12,000 setup.cfg files, though not all of them are necessarily Python package-related), blessing this behavior instead of purging it may actually be the simpler road to go in this specific case, for both users and setuptools' developers.

A second counter-argument is that it increases the complexity of simple string searches across large code repositories for specific keys. I don't disagree, but I'd note that supporting both options does not preclude individual teams maintaining a style requirement of using only underscores (or only dashes!) for their own sanity.

[jamesliu4c]

#4921

For the - _ issue, I am planning to propose a PR to indefinitely support either.

[jackklika]

Thanks for putting the work in!!

Python is becoming a language like english, and especially with new reliance on LLMs that may be trained on "not to spec" but de facto information, it's especially important to support "dialects" -- tokens with equivalent meaning. I hope other people take this approach.