Some changes pushed to main

[jaraco]

@webknjaz FYI - as part of my work in coherent-oss/roadmap#8, I pushed some changes directly to cheroot main. I don't want to disrupt the current RC release, so I'm going to disable force-pushes on main and back out those changes.

[jaraco]

I've done that by temporarily allowing force-pushes, pushing HEAD~2 to main, and then once again disabling force pushes to main. Now the proposed changes are in feature/pep-621, which I'll put through a PR.

[webknjaz]

Okay, it looks like I'll be releasing 10.0.1 from a separate branch so this shouldn't be in the way. Later, I wanted to debug more TLS-related tracebacks with some things only present locally currently.

[webknjaz]

Though, I do prefer having setup.cfg separate from pyproject.toml (as well as other configs) as it's easier to figure out where things are and sync across projects with less conflicts.

OTOH, with things like the dependency groups, it might make sense to host the metadata in pyproject.toml. I'm a little conflicted here.

[webknjaz]

I've done that by temporarily allowing force-pushes, pushing HEAD~2 to main

Are you sure you pushed the right commit back? I'm pretty the CI was green on the head of main before. Let me check if the last commit locally is the same...

[webknjaz]

Alrigh.. It looks the same:

* 3591a1ce - (origin/main, main) 💅 Keep empty line separators next to YAML marks (2 days ago) <Sviatoslav Sydorenko>

This likely means that something isn't pinned fully for the docs envs in the CI.. I'll have to figure it out then.

[webknjaz]

The most obvious difference is

- .pkg: packaging==24.0,pip==24.0,setuptools==69.1.0,setuptools-scm==8.0.4,tomli==2.0.1,typing_extensions==4.11.0,wheel==0.42.0
+ .pkg: packaging==24.0,pip==24.0,setuptools==69.5.1,setuptools-scm==8.0.4,tomli==2.0.1,typing_extensions==4.11.0,wheel==0.43.0
32

[webknjaz]

Though

WARNING: cannot cache unpickable configuration value: 'spelling_filters' (because it contains a function, class, or module object)

suggests it's a runtime thing, it shouldn't be related to packaging...

[jaraco]

I think it was Setuptools 69.3 that changed the names of sdists with dashes in the name.

[webknjaz]

@jaraco yes, but I don't think it's the cause. The Sphinx problem specifically does not seem to be caused by that, at least. I think that one might be related to Sphinx's caching but I don't understand why it didn't manifest itself earlier. Anyway, I'll try fixing it later since it's past midnight already.