Skip to content

python(grpc): build the LP and routing clients as one extension module - #1724

Closed
ramakrishnap-nv wants to merge 1 commit into
routing-grpc-vrp-e2efrom
grpc/unify-python-client
Closed

python(grpc): build the LP and routing clients as one extension module#1724
ramakrishnap-nv wants to merge 1 commit into
routing-grpc-vrp-e2efrom
grpc/unify-python-client

Conversation

@ramakrishnap-nv

Copy link
Copy Markdown
Collaborator

Stacked on #1597 (base is routing-grpc-vrp-e2e, since this needs the routing client that PR adds).

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). 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 — Client is already released and documented. Merging the declarations also collapses a drift between the two .pxd files, which described the same C++ class differently (routing omitted is_mip and most methods, and used bool where LP used bint).

Testing

Built and tested in a local .cuopt_env on an RTX 8000:

  • VRP end-to-end against a live cuopt_grpc_server — remote solve matches local; submit/wait/result/delete lifecycle passes. Server log confirms the real path (VRP problem reconstructedRoutingSolution).
  • LP/MIP gRPC client tests: 11 passed, 6 skipped (TLS certs absent locally).
  • Serialization coverage tests pass.
  • Verified at runtime that both import paths resolve to the merged .so and 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.

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
ramakrishnap-nv requested review from a team as code owners August 14, 2026 16:15
@ramakrishnap-nv
ramakrishnap-nv requested review from Iroy30 and jakirkham and removed request for a team August 14, 2026 16:15
@ramakrishnap-nv ramakrishnap-nv added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels Aug 14, 2026
@ramakrishnap-nv

Copy link
Copy Markdown
Collaborator Author

Folding this into #1597 instead.

Keeping it separate meant #1597 would add grpc/routing/grpc_client.{pyx,pxd} and this PR would immediately delete them — churn in main for no benefit, and review effort spent on files already slated for removal. The unification also has no standalone value, since it depends on the routing client #1597 introduces.

The commit is now on routing-grpc-vrp-e2e, and #1597's net diff shows only the end state: one cuopt/grpc/client/ extension module holding both arms, with the two public import paths preserved as shims.

@ramakrishnap-nv
ramakrishnap-nv deleted the grpc/unify-python-client branch August 14, 2026 16:17
@github-actions

Copy link
Copy Markdown

CI Test Summary

✅ All 22 test job(s) passed. (1 skipped)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant