feat(gfql): algorithm collection updates + version-sensitivity policy for igraph and cugraph CALL backends

[lmeyerov]

Background

pygraphistry#1614 added explicit local Cypher graphistry.nx.* CALL parity for 8 NetworkX algorithms (degree/closeness/eigenvector/katz/connected/strongly-connected/core_number/hits). pygraphistry#1618 (PR #1623) then formalized NetworkX/SciPy optional dependency policy via networkx + networkx-scipy extras, graphistry.plugins.networkx.policy, and graphistry/plugins/networkx/DEVELOP.md.

The same pattern is worth applying to the other two graph backends pygraphistry ships against: igraph and cugraph. Both currently lag the NetworkX baseline on algorithm-collection completeness, optional-dependency version policy, and plugin-local maintainer documentation.

Current state inventory

igraph

• Surface: to_igraph, from_igraph, compute_igraph, layout_igraph (graphistry/plugins/igraph.py)
• Algorithms: 28 in compute_algs; commented-out candidates biconnected_components, bipartite_projection, community_leading_eigenvector_naive, modularity
• GFQL CALL surface: monolithic compute_igraph(alg=...) dispatch via call/validation.py:599 safelist entry; no graphistry.ig.* local-Cypher CALL routes
• Version policy: setup.py extras has 'igraph': ['igraph'] — no upper-bound, no lower-bound pin
• Version detection: bare import igraph; no igraph.__version__ check or structured missing-feature guard
• Maintainer docs: none (no graphistry/plugins/igraph/DEVELOP.md)

cugraph

• Surface: to_cugraph, from_cugraph, compute_cugraph, compute_cugraph_core, layout_cugraph (graphistry/plugins/cugraph.py)
• Algorithms: node_compute_algs_to_attr (betweenness/katz/louvain/pagerank/etc), edge_compute_algs_to_attr (edge betweenness etc), graph_compute_algs; has _coerce_and_retry_cugraph fallback
• GFQL CALL surface: monolithic compute_cugraph(alg=...) dispatch via call/validation.py:584 safelist entry; no graphistry.cu.* local-Cypher CALL routes
• Version policy: cugraph-cu12==24.12.* pinned inside the rapids extra; no standalone cugraph extras_require entry; no cugraph-cu11 / version-flexible alternative
• Version detection: bare import cugraph; no cugraph.__version__ check or structured missing-feature guard; current saturation watch in pygraphistry#1058 plan calls RAPIDS 25.02 + 26.02 the supported smoke versions, which setup.py's rapids extra does not yet reflect
• Maintainer docs: none

Proposed scope

Mirroring the NetworkX precedent, deliver two coordinated tracks (can split into separate PRs if cleaner):

Track A — igraph

1. Algorithm collection updates:

   • Audit the 4 commented-out algorithms; re-enable any that have stable igraph support in the supported version window
   • Audit modern igraph (≥0.10) for newly-available algorithms worth surfacing (global_efficiency, local_efficiency, assortativity_*, transitivity_*, etc); add the most commonly-requested ones
   • Decide whether to add explicit graphistry.ig.* local-Cypher CALL routes (analog of graphistry.nx.* from #1614) or keep the monolithic compute_igraph(alg=...) dispatch as the canonical interface — recommend the explicit-route pattern for discoverability, but verify it fits the existing surface

2. Version policy:

   • Pin igraph extra with explicit lower + upper bounds based on the supported algorithms (suggest igraph>=0.10,<1 — verify against current code)
   • Add graphistry.plugins.igraph.policy analog of graphistry.plugins.networkx.policy
   • Add runtime version detection with structured missing-feature errors (fail-fast on unsupported version combos)

3. Plugin-local docs:

   • Add graphistry/plugins/igraph/DEVELOP.md with maintainer guidance for the algorithm/version surface

Track B — cugraph

1. Algorithm collection updates:

   • Audit cugraph 24.12 and the supported smoke versions (RAPIDS 25.02 + 26.02) for algorithms not yet in compute_cugraph's node_compute_algs_to_attr/edge_compute_algs_to_attr/graph_compute_algs maps
   • Decide whether to add explicit graphistry.cu.* local-Cypher CALL routes or keep monolithic dispatch (same call as Track A)
   • Verify _coerce_and_retry_cugraph graceful-fallback path still applies to new algorithms

2. Version policy:

   • Add a standalone cugraph extras_require entry (currently only ships via rapids) with explicit version-range support across CUDA stacks
   • Update rapids extra to reflect the supported RAPIDS 25.02 + 26.02 smoke versions per pygraphistry#1058 saturation watch
   • Add graphistry.plugins.cugraph.policy analog
   • Add runtime version detection with structured missing-feature errors

3. Plugin-local docs:

   • Add graphistry/plugins/cugraph/DEVELOP.md with maintainer guidance for the algorithm/CUDA-version surface

Non-scope

• No changes to compute_igraph(alg=...)/compute_cugraph(alg=...) public API shape — extensions only
• No changes to NetworkX surface from #1614/#1618
• No GFQL implementation shrink (this is feature-parity work)
• No new graph backend additions (focused on existing igraph + cugraph surfaces)
• No removal of monolithic dispatch in favor of explicit routes — both can coexist

Acceptance

• igraph CALL surface gains algorithm-collection updates per Track A
• cugraph CALL surface gains algorithm-collection updates per Track B
• Both gain explicit version-policy extras with structured version-detection
• Both gain plugin-local DEVELOP.md
• CI matrix validates both supported version bounds for each backend
• Compiler-plan surface untouched
• For cugraph track: DGX RAPIDS 25.02 + 26.02 cuDF smoke green pre-merge
• Anchored regression tests per new algorithm (mirror #1614 test pattern)

Cross-refs

• NetworkX precedent: pygraphistry#1614 (CALL parity), pygraphistry#1618/PR #1623 (version policy)
• Follow-on candidates that block on this: pygraphistry#1619 (compute_networkx(...) regular Python API parity may want analogous compute_igraph(...)/compute_cugraph(...) API normalization)
• Metaissue: pygraphistry#1058
• Coordination: tck-gfql may want to add scenario coverage for the new graphistry.ig.*/graphistry.cu.* routes (analog of tck-gfql#183/#187 NetworkX smoke scenarios) — file separate tck-gfql follow-on after this lands