or-tools: fix Python 3.14 support, drop broken marker - #551898
Open
gonsolo wants to merge 3 commits into
Open
Conversation
gonsolo
force-pushed
the
or-tools-python314-fix
branch
from
August 12, 2026 14:23
fde27db to
cbc66f0
Compare
gonsolo
force-pushed
the
or-tools-python314-fix
branch
from
August 17, 2026 11:09
e6f47ab to
9e0b3b5
Compare
gonsolo
added a commit
to gonsolo/Borg
that referenced
this pull request
Aug 17, 2026
klayout 0.30.7 (the previous pin) silently misses a real DRC violation (GR.2, sealring corner geometry) that 0.30.10 correctly catches -- traced by isolating the exact KLayout release across three toolchains while investigating wafer-space/gf180mcu-project-template#77. librelane bumps to 3.0.8 along the way (requested once NixOS/nixpkgs#551846 merged). yosys is 0.68 at this pin, which fixes the autoname O(iterations x module size) blowup upstream (YosysHQ/yosys#6050), so the local yosysFixed patch and its packages.${system} export are no longer needed. Pinned nixpkgs just past NixOS/nixpkgs#551902 (sv-lang_10 fix for fmt 12) rather than a same-day master commit or the nixos-unstable channel pointer -- the latter predates that fix by ~8h and hits the exact sv-lang build failure it resolves; a bleeding-edge commit has had no time to build/cache upstream at all. nixpkgs' own default python3 is 3.14 here, which breaks two of our deps with no released fix yet: - or-tools (openroad's dependency, transitively librelane's): its meta.broken is conditioned on pythonAtLeast "3.14" (real pybind11 test failures, NixOS/nixpkgs#551898 still open). Overridden back to python313 directly on that one package rather than the whole set, so openroad/librelane/klayout/yosys/pythonEnv all stay on nixpkgs' own default and keep hitting the binary cache. Also disables or-tools' own checkPhase: even on 3.13 it has one unrelated failure (python_contrib_check_dependencies, a stale pkg_resources/setuptools deprecation check -- 610/611 other tests pass), the same workaround NixOS/nixpkgs#551846's author used. - cocotb: no released Python 3.14 support upstream (cocotb/cocotb's setup.py hard-caps at 3.13; 3.14 support exists only on cocotb's unreleased master). Pinned to python313Packages.cocotb as its own nativeBuildInputs entry rather than folded into pythonEnv -- it doesn't need to share an interpreter with anything else, since test/soc/Makefile drives it via `cocotb-config --makefiles`, which points at cocotb's own bundled interpreter internally. Also: p.peakrdl -> p.peakrdl-cli (upstream rename), and beamer added to borgTexlive for docs/talk (ORConf 2026 slides, next commit). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018nC29cmxJCM5eiBBmWNY9q
Two independent, pre-existing issues blocked building or-tools under Python 3.14 (nixpkgs' current default): - The vendored pybind11 2.13.6 failed its own test suite (test_return_set_of_unhashable): Python 3.14 reworded TypeError's unhashable-type message so it no longer starts with "unhashable type:" (now embedded mid-message). pybind11's actual behavior is unchanged; backport the fix from upstream pybind/pybind11#5646, along with that PR's _Py_fopen_obj -> Py_fopen rename (3.14 removed the old symbol), fetched directly from the two upstream commits that introduce each change. - examples/contrib/check_dependencies.py imports `from pkg_resources import parse_version`, which current setuptools no longer provides. The import is unused dead code (parse_version is never called), so just drop it. Verified: pybind11's own test suite passes clean (1559 assertions, 17 test cases; 885 passed, 15 skipped), or-tools' full ctest suite passes (611/611), and `nix build .#or-tools` succeeds with no allow-broken workarounds needed. Assisted-by: Claude Code (Claude Sonnet 5)
Assisted-by: Claude Code (Claude Sonnet 5)
gonsolo
force-pushed
the
or-tools-python314-fix
branch
from
August 18, 2026 09:05
9e0b3b5 to
dcc0431
Compare
Contributor
Author
|
Hi @GaetanLepage, Next try:
|
Contributor
Author
|
Contributor
Author
|
The last `nixpkgs-review` failures on this PR (`or-tools`, `openroad`, Fix filed separately: #558488. I'll rebase this branch on top of it and |
CMake's find_package(absl) locates Abseil's package config via
CMAKE_PREFIX_PATH, which nixpkgs' cmake setup-hook populates from
buildInputs -- not nativeBuildInputs. With abseil-cpp/re2 listed under
nativeBuildInputs, -DGTEST_HAS_ABSL=ON fails configure:
CMake Error at CMakeLists.txt:25 (find_package):
Could not find a package configuration file provided by "absl"
or-tools is the only caller in nixpkgs that sets withAbseil = true (via
its checkInputs' gtest' = gtest.override { withAbseil = true; }), so
this latent bug was never triggered until now.
Verified: `gtest.override { withAbseil = true; }` builds cleanly, and
or-tools' full build (including its checkPhase, which needs gtest')
now succeeds end to end.
Contributor
Author
|
Contributor
Author
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two independent, pre-existing bugs that block building or-tools under Python 3.14
(nixpkgs' current default), found and diagnosed while bumping
openroad/librelane(whichdepend on
or-tools) to their latest releases.1. Vendored pybind11 2.13.6 test failure (
test_return_set_of_unhashable): Python 3.14reworded
TypeError's unhashable-type message so it no longer starts with"unhashable type:"(now embedded mid-message:"cannot use '...' as a set element (unhashable type: '...')"). pybind11's actual behavior is correct and unchanged — only the test assertion wastoo strict. Backported the relevant bits of upstream pybind/pybind11#5646
to the vendored 2.13.6 copy: the test-assertion loosening, plus the
_Py_fopen_obj->Py_fopenrename (3.14 removed the old symbol, would have been a separate latent break).That PR's other changes (CI/test-infra, a lazy
__annotations__code path added to pybind11after 2.13.6) don't apply here and were left out.
2.
examples/contrib/check_dependencies.py: doesfrom pkg_resources import parse_version, which current nixpkgssetuptools(83.0.0) no longer provides (upstreamsetuptools has deprecated/dropped
pkg_resources). Checked usage:parse_versionis neveractually called anywhere in this script — it's dead code — so the import is simply dropped
rather than reached for a
packaging.version.parsereplacement.With both fixed, dropped the
broken = python3.pythonAtLeast "3.14"meta marker.Verification
python_contrib_check_dependencies.nix build .#or-toolssucceeds with noNIXPKGS_ALLOW_BROKEN/--impureworkarounds needed.Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.AI disclosure: this PR description and the git/gh mechanics (branch, commit, push, PR
creation) were drafted/executed with the assistance of Claude Code (Claude Sonnet 5); see the
Assisted-by:trailer on each commit. Root-causing (tracing the actual pybind11 upstream fix,confirming
parse_versionis unused dead code) and the fix content itself were done with thatassistance and verified via the local builds described above.