python(grpc): build the LP and routing clients as one extension module - #1724
Closed
ramakrishnap-nv wants to merge 1 commit into
Closed
python(grpc): build the LP and routing clients as one extension module#1724ramakrishnap-nv wants to merge 1 commit into
ramakrishnap-nv wants to merge 1 commit into
Conversation
cuopt.grpc.linear_programming.Client and cuopt.grpc.routing.RoutingClient were two extension modules wrapping the same C++ object, cuopt::cython::grpc_python_client_t. Build them as one unit instead. The motivation is the client/engine split: if the gRPC client is ever detached from the solver engines as a GPU-free package, two units would each need their own copy of the transport layer (connect/TLS/submit/ status/poll/chunking). One unit keeps that a single package. See the discussion on #1635. The two public classes stay separate -- their feature sets genuinely differ, with log streaming, incumbents and chunked upload being LP-only and VRP unary-only -- and both keep their import paths, which matters because Client is already released and documented. Merging the declarations also collapses a drift: the two .pxd files described the same C++ class differently. The routing copy omitted is_mip from grpc_submit_result_t, omitted most methods, and used bool where the LP copy used bint. Each was independently trusted by the compiler. There is now one authoritative declaration. Two details worth recording: - solver_settings_t is a genuine collision (the LP one and cuopt::routing's are unrelated types), resolved by aliasing the routing one on its C++ name. - The merged .pxd must not cimport libcpp bool. Cython injects a same-named .pxd into its .pyx, so that shadows the Python builtin the LP arm calls as bool(job_complete). The routing setters take bint.
ramakrishnap-nv
requested review from
Iroy30 and
jakirkham
and removed request for
a team
August 14, 2026 16:15
Collaborator
Author
|
Folding this into #1597 instead. Keeping it separate meant #1597 would add The commit is now on |
CI Test Summary✅ All 22 test job(s) passed. (1 skipped) |
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
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.
Stacked on #1597 (base is
routing-grpc-vrp-e2e, since this needs the routing client that PR adds).cuopt.grpc.linear_programming.Clientandcuopt.grpc.routing.RoutingClientwere two extension modules wrapping the same C++ object (cuopt::cython::grpc_python_client_t). This builds them as one unit.Motivation is the client/engine split discussed in #1635: if the gRPC client is detached from the solver engines as a GPU-free package, two units would each need their own copy of the transport layer. One unit keeps it a single package.
Both public classes and both import paths are unchanged —
Clientis already released and documented. Merging the declarations also collapses a drift between the two.pxdfiles, which described the same C++ class differently (routing omittedis_mipand most methods, and usedboolwhere LP usedbint).Testing
Built and tested in a local
.cuopt_envon an RTX 8000:cuopt_grpc_server— remote solve matches local; submit/wait/result/delete lifecycle passes. Server log confirms the real path (VRP problem reconstructed→RoutingSolution)..soand no stale per-domain extension remains.Not covered locally: TLS/mTLS and chunked >2 GiB upload (both LP-only, unrelated to the merge).
Docs
No user-facing API change, so no doc updates. Module docstrings explain why the arms share a unit.