Name the Python extension after what it contains

[shoumikhin]

The compiled Python extension in the wheel was called _portable_lib. That name
is misleading in two ways. "Portable" is the name of a kernel set in this project,
the portable kernels, and this file does not contain them: it holds the Python
bindings for the runtime. "Lib" says nothing, since every shared object is a
library. Someone looking for the portable kernels finds the Python bindings
instead, and someone looking for the bindings has no reason to open a file named
after kernels.

Rename it to _C, which is the usual name for a package's compiled C extension
and what PyTorch calls the same thing (torch/_C.cpython-*.so). The package path
already says pybindings, as in executorch.extension.pybindings, so a name like
_pybindings would repeat itself while _C reads as "this package's C
extension".

The documented import path is unaffected. Applications import the public wrapper:

from executorch.extension.pybindings import portable_lib

That wrapper re-exports everything from the compiled module and keeps its name, so
code using it continues to work.

Code that imports the private module directly does break, and that pattern is in
real use despite the module being documented as experimental and subject to change.
No Python alias is added for the old name, since keeping the name reachable would
leave in place the thing this change exists to remove; such a caller moves to the
public wrapper. The C++ side is treated differently, because a CMake target name is
part of a published package interface rather than a private module: the package
config still answers to executorch::_portable_lib and to the bare _portable_lib
alongside executorch::_C.

Test plan:

Built a wheel and confirmed the shipped file is named for the new module:

extension/pybindings/_C.cpython-312-x86_64-linux-gnu.so

Installed that wheel into a fresh environment and checked both the public wrapper
and the private module load, then exported and ran a model through the Python
bindings:

public wrapper works: True
module name         : executorch.extension.pybindings._C
exported symbols    : 22

Also grepped the tree to confirm no build file, test, or comment still names the
old module.

[shoumikhin]

Stack from ghstack (oldest at bottom):

• -> Name the Python extension after what it contains #21816
• Ship linkable libraries in the macOS wheel #21771
• Ship the OpenVINO delegate as its own library #21770
• Build and publish CUDA wheels #21668
• Ship the CUDA delegate in the wheel #21645
• Ship the quantized kernels as their own library #21642
• Ship a C++ SDK in the wheel #21639
• Split the runtime out of the Python bindings extension #21610

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21816

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 12 New Failures, 23 Pending, 1 Unrelated Failure, 7 Unclassified Failures

As of commit 72fbbc3 with merge base 8bfb3a9 ():

NEW FAILURES - The following jobs have failed:

• Build Presets / windows (windows) / build (gh)
• Cadence Build & Test / hifi-build / hifi4 (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• pull / test-models-linux-basic (mv3, portable, cmake, linux.arm64.2xlarge, executorch-ubuntu-22.04-gcc11... / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• Test QNN Windows MSVC build / build-qnn-windows-msvc / windows-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• Test RISC-V Backend / test-riscv (mobilebert, true, true) / run / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• Test RISC-V Backend / test-riscv (resnet18, false, false) / run / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-cortex-m-e2e / run (mv2, cortex-m0plus) / mv2-cortex-m0plus (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-cortex-m-ops / run (cortex-m0plus) / cortex-m-ops-cortex-m0plus (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-llama-runner-linux (bf16, portable, linux.arm64.2xlarge, executorch-ubuntu-22.04-gcc11-aarch64) / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-models-linux-aarch64 (emformer_transcribe, portable, linux.arm64.2xlarge) / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-models-linux-aarch64 (llama3_2_vision_encoder, portable, linux.arm64.2xlarge) / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).
• trunk / test-torchao-huggingface-checkpoints (qwen3_4b, linux.arm64.2xlarge, executorch-ubuntu-22.04-gcc1... / linux-job (gh)
  ##[error]Response status code does not indicate success: 429 (Too Many Requests).

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_10-cuda12_6 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_10-cuda13_0 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_11-cuda12_6 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_11-cuda13_0 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_12-cuda13_0 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_13-cuda12_6 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22
• Build Linux CUDA Wheels / pytorch/executorch / build-manywheel-py3_13-cuda13_0 (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Failed to execute method forward, error: 0x22

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Apple / build-demo-ios / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 65

This comment was automatically generated by Dr. CI and updates every 15 minutes.