override_only config-settings rejected as hard-coded

[yosuke-konno-0414]

Hi, I think there is a validation bug around override_only settings when they are provided via PEP 517 config-settings.

I expected override_only fields such as cmake.toolchain-file and wheel.tags to be accepted when passed via -C..., but they are rejected with:

ERROR: cmake.toolchain-file is not allowed to be hard-coded in the pyproject.toml file

and similarly for wheel.tags.

Expected behavior

Settings marked as override_only=True should be:

• rejected when hard-coded in [tool.scikit-build]
• accepted when provided via:
  • [[tool.scikit-build.overrides]]
  • PEP 517 config-settings such as -Ccmake.toolchain-file=...

Actual behavior

When passing an override_only setting via config-settings, scikit-build-core appears to validate it as if it had been hard-coded in pyproject.toml.

Minimal repro

pyproject.toml:

[build-system]
requires = ["scikit-build-core==0.12.2"]
build-backend = "scikit_build_core.build"

[project]
name = "repro"
version = "0.0.1"

Then run:

uv build --wheel -Ccmake.toolchain-file=foo.cmake

Observed error:

ERROR: cmake.toolchain-file is not allowed to be hard-coded in the pyproject.toml file

I also see the same kind of failure with:

uv build --wheel -Cwheel.tags=cp312-abi3-win_amd64

Why this looks like a bug

From reading the validation code, it looks like _validate_overrides() does:

original_value = record.original_value if record else value

So if a setting came from config-settings, there is no override record, and the final merged value is treated as though it were the original pyproject value.

That seems to conflate:

• a value that was actually present in pyproject.toml
• a value that came from config-settings (-C...)

In other words, config-settings for override_only fields seem to be rejected because their source is not tracked separately from pyproject values during validation.

Environment

• scikit-build-core: 0.12.2
• frontend: uv build

[LecrisUT]

Hmm, good point. Afaik at that point the configs are already merged and we lost the source of those. Irc the sources are first merged when they are still raw dicts, but we are handling the overrides when they are already a dataclass. Ideas on how to approach this welcome