If I understand correctly the metric_closure function we currently use was implemented for the Kou steiner_tree algorithm. Issue #5889 and PR #7767 point out that computing all-pairs is more than what we need. So the current method uses single_source_djikstra with specifically chosen source nodes. So, we are left with a function that started out as a helper function for steiner tree until it was replaced and is now not used at all.

Actually, I know many places in our codebase where we do use a metric closure without calling it that. We just call it a all-pairs-shortest-path-length dict-of-dict. No need to store it as a Graph. We have the dict-of-dict and that's enough to what we need.

So, I suspect that we would choose not to include the metric closure function if we had to do it all over again. Can anyone think of a reason why have the metric_closure graph as a graph is better than having the all-pairs-shortest-path-length dict-of-dict?

If we do find a reason to keep a function called metric_closure, here are some questions to help determine where it should live:

• Is metric_closure an example of a unary operation?
• Is it comparable to something like complement or reverse?
  (If so, a place for it to go would be algorithms/operators/unary.py.)

Thanks @dschult - excellent points and the context from the linked PRs is very helpful. Given this state of thinks, my vote would be to deprecate metric_closure and (potentially) add a gallery example that highlights the term "metric closure" is synonymous(ish) with all_pairs_shortest_path_length.