Fixed for now in #473. We'll need to remember to uncap that when setuptools gets fixed.

Can you check c5defb8? That's a different fix

This didn't fix it? I see the same error in CI on this PR (previous run, when I reopen it, it will probably pass). Though, looking at it, I do think this is better that what is there currently, since this is actually not the package name, but the import name. Reopening.

Yeah, it's not a fix of the CI or anything, but just a leftover reference from when the project name got changed. This is not picked up by the CI because in all of them the project is built. (Although I'm not sure when this could be hit)

It always was scikit-build-core, it's just a mixup confusing package name (which is normalized to dashes) with import name - and importlib uses import name. I assume this throws an import error and follows the alternate path always.

Wait, but the project name in pyproject.toml is underscored. Doesn't it use the name from there?

_, -, and . are required to be equivalent for packages. packaging.utils.canonicalize_name converts them to dashes. So in theory, you should be able to choose your display name with some backends based on what you put in pyproject.toml, but that's the only effect. It seems that hatchling normalizes early in the process, so the display name has dashes no matter what. (I've always thought of it with dashes, so would change it if hatching started respecting dashes and dots for metadata).

I remember an issue where I had to convert dashes to underscores, probably in scikit-build, but maybe the issue was with the sdist archive and not with pypi or other

Yeah, we had some issues with normalization. They should be fixed in 0.5. Metadata should now respect whatever you enter, and the sdist name should be normalized to underscores.