AI analysis of open requests before 1.0

[henryiii]

🤖 AI text below 🤖

scikit-build-core 1.0 — Planning / Feature-Request Report

Derived from issues.db (134 open issues, no open PRs). Grouped by theme,
filtering out pure support/debugging questions. Each item lists the driving
issues so you can check off what belongs in 1.0.

Only 5 issues carry a milestone today: v1.0.0 → scikit-build/scikit-build#1145, #1147, #1148, scikit-build/scikit-build#1149;
v0.12.0 → #1105. Everything else below is unscheduled and is a candidate for
triage.

---

A. Explicit 1.0 release work (already milestoned)

• Release 1.0.0 #1145 — 1.0.0 tracker issue (milestone 6).
• Removing the deprecated fields in 1.0.0 release #1148 — Remove deprecated fields right before release (e.g. cmake.targets).
• Improve usability of config reference section #1147 — Improve the config-reference docs: show each option in
  pyproject.toml / config-settings / env-var form, link back to main docs.
• Document the experimental features better #1149 — Review & document the experimental features (hatch plugin,
  setuptools shim, etc.), give each a tracking issue + dedicated doc page.

These four are the de-facto 1.0 definition-of-done. Everything else is "do we
pull it forward into 1.0 or defer to 1.x."

---

B. Stabilizing the public surface (strong 1.0 candidates)

A 1.0 is mostly about freezing the config/API contract. These decide what that
frozen surface looks like:

• Deprecating [pyproject] optional-dependency #882 — Deprecate/remove the empty [pyproject] optional-dependency group
  (cleanup; pairs with Removing the deprecated fields in 1.0.0 release #1148).
• Setuptools plugin status #320 / feat(setuptools): cmake_install_dir #316 / feat(setuptools): cmake_process_manifest_hook #317 / feat(setuptools): cmake_with_sdist #319 — Setuptools-plugin parity status. Decide what's
  in vs. permanently warned, since the setuptools layer is slated to split out.
• Unify wheel builders #881 — Unify the wheel builders (one common WheelBuilder shared by the
  build backend and the hatch/setuptools plugins). Architectural; unblocks
  editable support in the hatch plugin. Worth doing before freezing internals.
• Devendoring pyproject_metadata #933 — Devendor pyproject_metadata (waiting on packaging absorbing the
  interface). Tracker; affects test checksums.

---

C. Configuration / overrides expressiveness

Recurring requests to make config more powerful — relevant to 1.0 because each
adds frozen surface:

• Add a static file as potential source of configuration #1301 — Static config-file source + a scikit-build-core.config
  entry-point (Fedora wants to opt out of debug-symbol stripping).
• Ability to set environment variables in pyproject.toml #1114 — Set environment variables from pyproject.toml (CC/CXX clobbering
  is biting the Chapel team).
• Override if Option Around CMake Build Type? #591 — More if.* override keys, notably if.editable.
• Question: Is There a Way to Enable Extras in tool.scikit-build.overrides? #908 — Trigger build config from extras (pip install .[mpi]).
• Cannot specify search prefixes in pyproject.toml #1151 — Specify CMake search prefixes in pyproject.toml
  (search.prefixes).
• Support SKBUILD_CONFIGURE_OPTIONS and SKBUILD_BUILD_OPTIONS #380 — SKBUILD_CONFIGURE_OPTIONS / SKBUILD_BUILD_OPTIONS (classic
  parity).
• Support semicolon-separated lists in SKBUILD_CMAKE_ARGS #927 — Handle semicolon-separated lists inside SKBUILD_CMAKE_ARGS.
• feat: ignore-vcs option #277 — ignore-vcs option / way to disable .gitignore-based selection.

---

D. Dynamic metadata system

The largest design thread in the tracker. Mostly a multi-release / cross-PEP
effort — likely not 1.0-blocking, but worth a documented stance:

• Plan for metadata proposal #230 — "Plan for metadata proposal" (54 comments). Became a
  discuss.python.org PEP for dynamic-metadata plugins; v2 of the proposal was in
  progress. This is the umbrella design.
• Extract metadata from cmake #172 — Extract metadata (esp. version) from CMake (24 comments). Active
  as of mid-2025; needs native support to share build dir/generator with the
  dynamic-metadata providers.
• Dynamic metadata: entry-points possible? #296 — Dynamic entry-points / scripts.
• Dynamic license field #995 — Dynamic license field (bundled vs. linked deps; needs PEP 639
  follow-up; sdist-vs-wheel divergence is the hard part).
• Pass config settings to setuptools_scm #585 — Forward config-settings to the setuptools_scm plugin.
• Supporting setuptools-git-version as a version provider #1257 — Add setuptools-git-version as a version provider.

---

D2. Shared-library / wheel-repair / RPATH (biggest user-pain cluster)

The most-reported real-world failure mode. Currently out of scope (users defer
to auditwheel/delocate/delvewheel), but demand is high:

• Q: is wheel repairing in the scope of this project? #624 — Is wheel repair in scope at all? (the framing issue)
• Helpers for handling RPATH and company #1002 — Helpers for RPATH / LD_LIBRARY_PATH / os.add_dll_directory();
  LecrisUT has a prototype using the CMake file-API.
• ABI builds fails due wheel repair for dynamic libraries #1118 — ABI/limited-API builds fail under wheel repair for dynamic libs.
• Question: Distributing CMake Configs #1024 / SKBUILD_DATA_DIR install destination results in an absolute _IMPORT_PREFIX #894 — Distributing CMake configs: absolute _IMPORT_PREFIX /
  SKBUILD_DATA_DIR leaks the temp install path into installed config files.
• CMake design: How to make vanilla CMake installs play nice with python packaging #856 — Make vanilla cmake --install coexist with Python packaging.
• Linker Symbols get Lost after shared library is moved to site-packages. #1121 / Windows: DLL copied to the wrong directory #883 / Editable Mode install rebuilds don't update *.so in site-packages #1135 / scikit-build/scikit-build#1152 / Linking discrepancy compared to manual cmake and makefile invocation #1173 — .so/DLL placed in wrong dir or
  symbols/sonames lost after move to site-packages.

Recommendation: this is too big for 1.0, but #624 deserves a documented
in-scope/out-of-scope decision, and #1002/#894/#1024 (config-file path
fixes) are smaller and high-value.

---

E. Editable-install robustness

Many small correctness bugs; collectively a credibility issue for 1.0:

• editable mode ignores build-dir and writes CMake files directly into source tree #1106 — editable.mode = "inplace" ignores build-dir, pollutes source tree.
• Invalid soname for known_wheel_files in editable mode #1144 — Invalid soname for known_wheel_files in editable mode.
• Editable Mode install rebuilds don't update *.so in site-packages #1135 — Editable rebuilds don't update *.so in site-packages.
• Editable installs with paths involving symlinks may include incorrect directories in __path__ #647 — Symlinked package dirs produce wrong __path__ entries.
• Presence of hidden files breaks editable installs #437 — Nested .gitignore / hidden files break editable installs.
• Import issues in editable install when using complicated wheel.packages options #1040 — Editable import issues with complex wheel.packages / namespaces.
• AssertionError: "Editable installs cannot rebuild an absolute wheel.install-dir. Use an override to change if needed." #909 — Editable install rejected when wheel.install-dir is absolute.
• Editable install can cause a pytest warning #1327 — Editable install triggers a pytest warning (pre-7.2 finder issue).
• Editable install fails in Jupyter notebook #926 / Scikit-build Community Meeting #26: 2025-01-17 scikit-build#1141 / Editable install #114 — Jupyter, cython+ctypes shared lib, base tracker.

---

F. SDist improvements

• sdist.include can not work #1105 (milestoned v0.12) — sdist.include over-includes / ignores
  .gitignore.
• Manual excludes with manual includes #858 — Define precedence between manual sdist.exclude and sdist.include.
• Allows build_sdist to dereference links  #943 / When building sdist, file symlink remains a symlink instead of being copied to a concrete file #801 — Option to dereference symlinks when building the sdist
  (PoC exists in Allows build_sdist to dereference links  #943).
• Prevent infinite loops in build_sdist #1101 — Prevent infinite loops in build_sdist (circular symlinks after fix: follow symlinks when making SDists #362).
• Should the sdist use git-archive? #604 — Should sdist use git-archive (for .git-archival.txt etc.)?
• Option to run more in the SDist step? #837 — Allow running cmake --install in the sdist step (header-only pkgs).
• Generate sdist out of the source tree #1237 — Generate sdist out of the source tree (Apache Arrow / PyArrow).
• Reproducible builds #62 — Reproducible builds: set wheel timestamps (sdist already done).

---

G. Cross-compilation & platform tags

• Cross-compilation support #1041 — First-class cross-compile support (cmake.toolchain, wheel.py-api,
  PEP 720 alignment). Author volunteered; needs design. CMake 4.1 broke crossenv
  on conda-forge (Cross-compilation support #1041 latest).
• Configuration of platform tag #606 / Platform Tag Improperly Set for Mac OS Wheels #977 — Configurable platform tag / MACOSX_DEPLOYMENT_TARGET
  without env-var-only workarounds.
• Windows library investigation #1026 / Bug in setting SKBUILD_SOABI for Windows ARM #690 — Windows: avoid requiring the Interpreter component (helps
  cross-compile); SKBUILD_SOABI bug on Windows ARM.
• Cross compiling fortran projects on cibuildwheel fails #505 — Fortran universal2 cross-compile on cibuildwheel.
• Handling microarchitecture subversions #938 — Microarchitecture variants (glibc-hwcaps, x86-64-vN).

---

H. Windows / compiler & generator selection

• Ninja build on Windows #934 / Moving check-sdist to scikit-build? scikit-build#1089 — Ninja on Windows (MSBuild is very slow; Moving check-sdist to scikit-build? scikit-build#1089: arch wrongly
  passed to Ninja generator).
• Should scikit-build pick the right compiler on Windows automatically? #668 — Auto-pick the right compiler/arch on Windows.
• cibuildwheel on Github Actions Windows runner uses GCC by default #587 / scikit-build f2py compile error with full path of signature file on Windows: Perhaps anyone here can help out? scikit-build#822 / Building with MinGW on Windows fails #900 — Honor GCC/MinGW when requested instead of MSVC.
• Targets on MSVC #735 — Document/support MSVC target-name differences.

---

I. CMake-config / entry-point integration

• Entrypoints design for projects declaring components #113 — Entry-point design for projects declaring CMake components
  (cmake.root / cmake.module / cmake.prefix).
• Entry points do not work for namespace packages #682 — Entry-point CMake paths broken for namespace packages.
• Create a FindScikitBuildCore.cmake module #902 — Ship a FindScikitBuildCore.cmake module (try_compile checks, ABI
  verification, component exposure).

---

J. Build types / multi-config

• Package multiple configs? #873 — Package multiple configs (e.g. ship Debug binaries alongside Release).
• RFE: Set the default build type in RPM builds to RelWithDebInfo #915 — Default RPM build type to RelWithDebInfo (Fedora debuginfo).
• Debug build setting not passed to CMake build config in Conda-forge #663 / tool.scikit-build.cmake.build-type does not not work for windows platform. #578 / Problems with Debug build on Windows #670 — Debug build-type not propagated (conda-forge / Windows).

---

K. Build-experience features (smaller, mostly 1.x)

• Support parallel build and alternative linkers, especially mold #163 — Parallel build + alternative linkers (mold).
• Possible to Get Colored Output from Compiler? #622 — Colored compiler output.
• Custom error message on failure (maybe by hook?) #111 — Friendly custom error message on failure (hook).
• Executing Python commands from pyproject.toml #685 — Run Python validation commands from pyproject.toml.
• feat: force-include #776 — hatchling-style force-include.
• Inclusion of stub files #713 / Option to import pyi stubs as modules #978 — Ship/handle .pyi stub files (incl. importing stubs as
  modules for docs builds).
• Working with gcovr #621 — gcovr compatibility (copied files break coverage).

---

L. Internal: build-isolation, dev infra, docs, examples

• Should we workaround pip's build isolation bugs? #993 — Work around pip's build-isolation bugs (pip-build-env-*); upstream
  fix stalled, uv already works around it.
• tests: cover uv as an install frontend (editable + build isolation) #1328 / Running tests with pip --no-index #1027 / Tests hardcode the use of pip for downloading a lot of dependencies #720 — Test infra: cover uv as an install frontend; run
  tests without network / with --no-index; stop hardcoding pip downloads.
• Separating the CI for docs #381 — Split docs CI from the full build matrix.
• cookie-cutter project #539 / Scikit-build Community Meeting #12: 2023-10-20 scikit-build#1034 — Cookiecutter template + shared-library linking example.
• Stateful File API queries #446 / Tracking scikit-build -> scikit-build-core migrating projects #796 — Evaluate madebr/python-cmake-file-api; migration tracker.

---

Suggested 1.0 cut (my read)

Must-do (already the milestone): scikit-build/scikit-build#1145, #1147, #1148, scikit-build/scikit-build#1149.

Pull into 1.0 (freeze-the-surface, low risk): #882, #320-family decision,
#881 (builder unification), and a documented in/out-of-scope statement for wheel
repair (#624). Plus the v0.12 sdist fix #1105.

High-value, fits if there's room: config sources #1301 / #1114 / scikit-build/scikit-build#1151;
sdist correctness #858 / #1101 / #943; editable bug-bucket scikit-build/scikit-build#1106 / scikit-build/scikit-build#1144 / #1135.

Explicitly defer to 1.x (too big / cross-PEP): dynamic-metadata system
(#230/#172/#995), full cross-compilation (#1041), wheel-repair implementation
(#1002/#1118), multi-config packaging (#873).

[henryiii]

And here's the summary version:

🤖 AI text below 🤖

I've written the report to 1.0-planning-report.md. Here's the summary.

What's in the tracker

134 open issues, no open PRs. Only 5 are milestoned: v1.0.0 → scikit-build/scikit-build#1145, #1147, #1148, scikit-build/scikit-build#1149; v0.12.0 → #1105. Everything else is unscheduled, so the real planning work is deciding what to pull forward.

The de-facto 1.0 definition (already milestoned)

• Release 1.0.0 #1145 tracker · Removing the deprecated fields in 1.0.0 release #1148 remove deprecated fields (cmake.targets etc.) · Improve usability of config reference section #1147 config-reference docs · Document the experimental features better #1149 review & document experimental features (hatch/setuptools).

The big themes being proposed

Theme	Driving issues	1.0 verdict (my read)
Stabilize public surface	#882, #320/#316/#317/#319, #881 (unify builders), #933	Pull in — this is what a 1.0 freezes
Config/override power	#1301, #1114, #591, #908, scikit-build/scikit-build#1151, #380, #927, #277	Cherry-pick the cheap ones
Dynamic metadata	#230 (54c, became a PEP), #172 (version from CMake), #296, scikit-build/scikit-build#995, #585, #1257	Defer — cross-PEP, multi-release
Wheel repair / RPATH / .so placement	#624, #1002, scikit-build/scikit-build#1118, scikit-build/scikit-build#1024, #894, #856, +5 dup-pain reports	Biggest user pain; defer impl but decide scope (#624)
Editable robustness	scikit-build/scikit-build#1106, scikit-build/scikit-build#1144, #1135, scikit-build/scikit-build#647, #437, #1040, #909, #1327	Bug-bucket; credibility for 1.0
SDist	#1105, #858, #943, #1101, #604, #837, #1237, #62	Several small correctness wins
Cross-compile / platform tags	scikit-build/scikit-build#1041, #606, #977, #1026, #505, #938	Defer the big one (#1041)
Windows/Ninja/compiler	#934, scikit-build/scikit-build#1089, #668, #587/#822/#900	Ongoing support, not 1.0-gating
CMake-config entry-points	#113, #682, #902	Design-stage
Build types/multi-config	#873, #915, #663	Defer

My suggested 1.0 cut

• Must-do: the 4 milestoned issues.
• Pull in (freeze the surface, low risk): Deprecating [pyproject] optional-dependency #882, the setuptools-plugin status decision (Setuptools plugin status #320), Unify wheel builders #881 builder unification, a documented scope statement for wheel repair (Q: is wheel repairing in the scope of this project? #624), and the v0.12 sdist fix sdist.include can not work #1105.
• If there's room: config sources Add a static file as potential source of configuration #1301/Ability to set environment variables in pyproject.toml #1114/Cannot specify search prefixes in pyproject.toml #1151; sdist correctness Manual excludes with manual includes #858/Prevent infinite loops in build_sdist #1101/Allows build_sdist to dereference links  #943; editable bugs scikit-build/scikit-build#1106/Invalid soname for known_wheel_files in editable mode #1144/Editable Mode install rebuilds don't update *.so in site-packages #1135.
• Defer to 1.x: dynamic-metadata system, full cross-compilation (Cross-compilation support #1041), wheel-repair implementation, multi-config packaging.

The two largest discussion threads worth your own eyes: #230 (metadata PEP, 54 comments — moved to discuss.python.org) and #172 (version-from-CMake, active mid-2025). #1017 (46c) and scikit-build/scikit-build#1139 (30c) are high-comment but are support/debugging, not proposals.

One note: the report is opinionated about the cut — adjust the "Suggested 1.0 cut" section as you triage; it's structured so you can check items off.