NetworkX 3.x Backend Dispatch: Pin Priority or Accept Environment-Dependent Fallback?

Backend dispatch changed the reproducibility picture in NetworkX 3.x

NetworkX 3.x added a pluggable backend system: graph algorithms can be dispatched to alternative implementations that register themselves through Python entry points, while the pure-Python API stays the same. Selection is influenced by per-call backend arguments and documented configuration such as the NETWORKX_BACKEND_PRIORITY setting; exact names and defaults vary across 3.x minor releases, so the pinned release notes govern.

For a repeatable development environment, the sticking point is fallback. Backend availability is discovered at import time, so a lockfile that pins networkx but leaves backend packages unpinned can change which implementation runs without any code change. When a backend cannot handle a graph or algorithm, NetworkX may convert the graph and fall back to the default implementation — a path that can dominate runtime on large graphs and make timings non-comparable between a workstation and CI.

A project therefore has to choose a dispatch policy rather than inherit one by accident.

1. Should automatic backend-to-core conversion be treated as a compatibility feature, or should environments fail fast when the preferred backend is unavailable?
2. Where should priority live — the NETWORKX_BACKEND_PRIORITY environment variable, project-level configuration, or explicit per-call arguments — so developer machines and CI resolve the same implementation?