_osx_support._default_sysroot(cc) has no caller inside CPython, yet several downstream projects import it directly and there is no public replacement to send them to.
Lifecycle
Downstream use
A GitHub code search finds live callers: pyston (setup.py), PyOxidizer (vendored distutils/unixccompiler.py), and the macports and fink Python patches. They call it to discover the SDK sysroot when compiling extensions.
No public replacement
sysconfig does not expose the SDK sysroot and distutils is gone, so a downstream user has nowhere supported to move. They would shell out to xcrun --show-sdk-path or copy the function body.
Question
For this private helper with live downstream use and no public equivalent, which way do we go:
- Keep it as-is and document that it is unsupported.
- Add a supported public equivalent first, then deprecate and remove.
- Remove it now under the "private API carries no guarantee" rule and accept the breakage.
_osx_support._default_sysroot(cc)has no caller inside CPython, yet several downstream projects import it directly and there is no public replacement to send them to.Lifecycle
distutils. gh-92584: Remove the distutils package #99061 (PEP 632: Remove the distutils package (Python 3.12) #92584) removeddistutils, so nothing in CPython calls it now.Downstream use
A GitHub code search finds live callers: pyston (
setup.py), PyOxidizer (vendoreddistutils/unixccompiler.py), and the macports and fink Python patches. They call it to discover the SDK sysroot when compiling extensions.No public replacement
sysconfigdoes not expose the SDK sysroot anddistutilsis gone, so a downstream user has nowhere supported to move. They would shell out toxcrun --show-sdk-pathor copy the function body.Question
For this private helper with live downstream use and no public equivalent, which way do we go: