Background
Publishing cuOpt to pypi.org (instead of only pypi.nvidia.com) would simplify installation, remove the need for --extra-index-url, and unblock security-conscious users who restrict installs to the main PyPI index.
The blocker is package size. The current libcuopt-cu12 wheel is ~542 MB compressed. PyPI enforces a 1 GB per-package limit and a soft 100 GiB per-project limit; headroom exists today but is not comfortable enough to commit to indefinitely, especially with features like multi-GPU PDLP added recently.
What this issue tracks
Split the single libcuopt wheel into separate wheels along solver boundaries, e.g.:
libcuopt-routing-cu12 — routing/VRP engine (libcuopt_routing.so, libcuopt_base.so)libcuopt-lp-cu12 — LP/MILP/QP solver (libcuopt_lp.so, libcuopt_base.so)libcuopt-grpc-cu12 — gRPC client (libcuopt_grpc.so)
The corresponding Python meta-packages (cuopt-vrp, cuopt-lp, etc.) would declare only the lib package they need, so users who only use routing don't pull in the LP solver and vice versa.
Prerequisites
PR #1622 (feat/split-routing-lp-libs) splits the monolithic libcuopt.so into component .so files (libcuopt_base, libcuopt_routing, libcuopt_lp, libcuopt_grpc). That clean boundary is required before this package split is possible without rearchitecting the C++ build. This issue should not be started until that PR merges.
Prior art
A POC splitting cuOpt into cuopt-common + per-solver packages was explored previously but deferred for other priorities. The .so boundary work in #1622 makes this cleaner than the prior attempt.
Work involved
- New
ci/build_wheel_libcuopt_{routing,lp,grpc}.sh scripts (modeled on existing ci/build_wheel_libcuopt.sh)
- New
python/libcuopt_{routing,lp,grpc}/ package directories with pyproject.toml
- Update
python/cuopt/pyproject.toml optional-dependency groups to reference the split packages
- Update conda recipes accordingly
- Verify compressed sizes stay well under 750 MB per package (per RAPIDS guidance)
- Coordinate with RAPIDS build-infra on PyPI org registration (see rapidsai/build-infra#356)
Target
26.10 (too late for 26.08)
Background
Publishing cuOpt to pypi.org (instead of only pypi.nvidia.com) would simplify installation, remove the need for
--extra-index-url, and unblock security-conscious users who restrict installs to the main PyPI index.The blocker is package size. The current
libcuopt-cu12wheel is ~542 MB compressed. PyPI enforces a 1 GB per-package limit and a soft 100 GiB per-project limit; headroom exists today but is not comfortable enough to commit to indefinitely, especially with features like multi-GPU PDLP added recently.What this issue tracks
Split the single
libcuoptwheel into separate wheels along solver boundaries, e.g.:libcuopt-routing-cu12— routing/VRP engine (libcuopt_routing.so,libcuopt_base.so)libcuopt-lp-cu12— LP/MILP/QP solver (libcuopt_lp.so,libcuopt_base.so)libcuopt-grpc-cu12— gRPC client (libcuopt_grpc.so)The corresponding Python meta-packages (
cuopt-vrp,cuopt-lp, etc.) would declare only the lib package they need, so users who only use routing don't pull in the LP solver and vice versa.Prerequisites
PR #1622 (
feat/split-routing-lp-libs) splits the monolithiclibcuopt.sointo component.sofiles (libcuopt_base,libcuopt_routing,libcuopt_lp,libcuopt_grpc). That clean boundary is required before this package split is possible without rearchitecting the C++ build. This issue should not be started until that PR merges.Prior art
A POC splitting cuOpt into
cuopt-common+ per-solver packages was explored previously but deferred for other priorities. The.soboundary work in #1622 makes this cleaner than the prior attempt.Work involved
ci/build_wheel_libcuopt_{routing,lp,grpc}.shscripts (modeled on existingci/build_wheel_libcuopt.sh)python/libcuopt_{routing,lp,grpc}/package directories withpyproject.tomlpython/cuopt/pyproject.tomloptional-dependency groups to reference the split packagesTarget
26.10 (too late for 26.08)