Disallow deprecated dash-separated and uppercase options in setup.cfg

[abravalheri]

Summary of changes

@jaraco, this is a possible approach for #4864, if we are feeling brave.
But it can break packages that have not addressed the warning.

Closes #4864

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[abravalheri]

I moved this function out of the class to allow caching without memory leaks (otherwise it would keep a reference to self).

[jaraco]

I'm inclined to say we should do it, even though it will cause some disruption.

The only other options I can think of are:

1. Fail intermittently, so users can retry and succeed but also get the signal that something is broken and start complaining to the offending project.
2. During the deprecation warning, sleep for some time, giving users a chance to ponder their life choices and maybe investigate the cause, motivating complaints to the offending project.
3. Develop a more sophisticated signal from deprecations in build backends to the offending projects.
4. Roll back the deprecations and just accept the status quo.

The first three are really about the deprecation strategy of this project and not this specific deprecation. Given that to date, the deprecation process we have in place is the best process available, I'm inclined to just push forward with it, though I'm open to delay these depreciations if we think the churn or disruption is too great.

[jaraco]

We'll want a news fragment that clearly describes what the change was, how to respond to it, and links to more detailed rationale for why it was changed.

[abravalheri]

Thank you very much for the review @jaraco.

We'll want a news fragment that clearly describes what the change was, how to respond to it, and links to more detailed rationale for why it was changed.

The best I could find for the rationale behind the deprecation was v54.1.0 (#1608) and v54.1.1 (#2592). I added those to the news fragment. hopefully that is OK.

[DavidCain]

Given that to date, the deprecation process we have in place is the best process available, I'm inclined to just push forward with it, though I'm open to delay these depreciations if we think the churn or disruption is too great.

Can there be an option to disable enforcement of no-dash naming? This does indeed break installation of some packages when using latest setuptools. Obviously, fixing the packages (or upgrading to newer versions) is preferable, but not always practical!

[zanieb]

We're already seeing this causing disruptions in the ecosystem via bug reports to uv and core packages like requests are in violation here (https://github.com/psf/requests/blob/main/setup.cfg). I think this should be reverted.

If the ecosystem had better support for locking and constraining build dependencies, the trade-offs may be different but unfortunately that's not the case yet.

[systemsoverload]

+1 this is causing a massive disruption in all of our builds. There are just too many legacy packages that violate this paradigm to not have an override option of some kind. I would ask that this be reverted while a discussion can be had on workarounds

[toby-j]

[tool.uv]
build-constraint-dependencies = ["setuptools<78"]

Tried adding this, but getting the same error.

[zanieb]

@toby-j for workarounds in uv, see astral-sh/uv#12440

[danielcarcich]

Unexpected build issues I didn't need in my life come Monday morning. Please roll it back and remove the deprecation warning. There's no practical downside to supporting the old convention indefinitely.

[michaelpavkovic]

I would strongly encourage this change to be rolled back (@jaraco's 4th recommendation). This change will break countless builds pretty much everywhere. We all either directly or indirectly rely upon a version of some package (it may even be a super big popular one), where a dash is used in setup.cfg.

At my place of work, I'm noticing all of my team's builds breaking and we will not be able to use the latest version of setuptools anywhere if this change is kept in place.

Even though this was warned about years back, we can't rely upon every 3rd party dependency to fix these formatting issues.

[christianfobel-telus]

we will not be able to use the latest version of setuptools anywhere if this change is kept in place.
...
Even though this was warned about years back, we can't rely upon every 3rd party dependency to fix these formatting issues.

Exactly this.

[cspades]

Hi, pysox is affected as well: https://github.com/marl/pysox/blob/master/setup.cfg#L2! Revert or add some legacy option to make this more flexible! 🙏🏻

[jeff-omni]

neptune is affected from its dependency on bravado-core; see Yelp/bravado-core#411 for a fix, but we are at the mercy of the package maintainers

[ghananigans]

Looks like the change was reverted and a new release has been made 🎉

[ianballard]

Please see this open issue Urgent: Governance and Change Management Review After Breaking Change in #4870