Pyomo cuOpt adapter: TypeError formatting _version aborts pytest collection (thirdparty pyomo, 12/12 nightly jobs)

[ramakrishnap-nv]

Summary

Pyomo's cuOpt adapter (pyomo/solvers/plugins/solvers/cuopt_direct.py) raises TypeError while formatting the solver name from CUOPTDirect._version. Because this happens at import/plugin-resolution time, it aborts pytest collection, so the entire thirdparty pyomo step fails rather than a single test.

This is not CI-only: any Pyomo user who has cuOpt installed hits this as soon as Pyomo resolves its solver plugins.

Observed in

Nightly run 32220613929 (main @ 1dbab9cf, 2026-08-19) — 12 of 12 wheel-tests-cuopt jobs fail the thirdparty pyomo step.

Deterministic and long-standing: also 12/12 in 32104333527 (2026-08-18), and wheel-tests-cuopt has failed 12/12 in every nightly checked back to 2026-08-14.

Independent of CUDA version, arch, Python version, and driver — it reproduces across 12.2.2 / 12.9.2 / 13.0.3 / 13.3.0, amd64 and arm64, py3.11–3.14.

Traceback

ERROR collecting pyomo/solvers/tests/checks/test_BARON.py
pyomo/solvers/tests/checks/test_BARON.py:23: in <module>
    baron_available = _test_solver_cases('baron', 'bar').available
pyomo/solvers/tests/solvers.py:445: in test_solver_cases
    _test_solver_cases['cuopt', 'python'] = initialize(
pyomo/solvers/tests/solvers.py:47: in initialize
    elif not opt.available(exception_flag=False):
pyomo/solvers/plugins/solvers/direct_or_persistent_solver.py:314: in available
    return bool(_api)
pyomo/common/dependencies.py:347: in __bool__
    self.resolve()
...
pyomo/solvers/plugins/solvers/cuopt_direct.py:37: in _get_cuopt_version
    CUOPTDirect._name = "cuOpt %s.%s%s" % CUOPTDirect._version
E   TypeError: not all arguments converted during string formatting

!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
====================== 6440 deselected, 1 error in 5.05s =======================

Analysis

"cuOpt %s.%s%s" % CUOPTDirect._version requires _version to be a 3-tuple. _version now has more than three elements, so the % operator raises TypeError: not all arguments converted during string formatting.

The likely trigger is a change in the shape of the version cuOpt reports (e.g. a 4-component version, or an extra suffix/build component being included when the tuple is built). Worth confirming what _version actually contains against a current cuOpt build before settling on the fix.

Suggested fix

The offending line lives in Pyomo, not in this repo, so the fix needs a PR upstream to Pyomo. Make the formatting length-agnostic rather than assuming three components, e.g. joining the parts instead of positional %s placeholders.

In the meantime, this repo's ci/thirdparty-testing/ Pyomo step will keep failing on every nightly, which also masks any genuine Pyomo-integration regression behind a collection abort.

Follow-up needed

• Confirm the actual value/length of CUOPTDirect._version with a current cuOpt build
• File and land a PR against Pyomo fixing cuopt_direct.py
• Decide whether to pin/patch Pyomo in ci/thirdparty-testing/ until the upstream fix ships, so the step stops failing every night

Related

Filed alongside the other thirdparty nightly failures from the same run: #1485 (JuMP SOC bridge segfault, reopened) and the cvxpy build failure.

[ramakrishnap-nv]

Root cause confirmed, and the upstream fix is up: Pyomo/pyomo#4026.

The trigger is the nightly wheel version specifically. Wheels carry a PEP 440 .post suffix:

package	cuopt.__version__	components	result
nightly wheel	26.10.0a37.post260819050903	4	TypeError
nightly conda	26.10.00a37	3	no error
release	26.10.00	3	no error

"cuOpt %s.%s%s" % tuple(version.split('.')) needs exactly three components, so the extra .post… segment raises not all arguments converted during string formatting. That matches the observation that only wheel-tests-cuopt jobs failed the thirdparty pyomo step.

Worth noting the 3-component path was already subtly wrong — 26.10.00 rendered as cuOpt 26.1000, because %s.%s%s drops the second separator. The pattern was carried over from gurobi_direct.py, where gurobipy.gurobi.version() returns a fixed-length tuple of ints; a PEP 440 string split on . doesn't have that shape.

The fix formats from the version string directly, so it's correct for any number of components:

-    CUOPTDirect._name = "cuOpt %s.%s%s" % CUOPTDirect._version
+    CUOPTDirect._name = "cuOpt %s" % (cuopt.__version__,)

This ticks the first two follow-up boxes. The third — whether to pin/patch Pyomo in ci/thirdparty-testing/ until the upstream fix ships — is still open. Given the step fails on every nightly and aborts collection (so it masks any genuine Pyomo-integration regression behind it), some interim mitigation is probably worth it.