Handle SPEC 2

[stefanv]

• [x] Remove attached website @jarrodmillman
  • [x] #239 @jarrodmillman
  • [x] Save meeting notes @jarrodmillman archived https://github.com/scientific-python/api-dispatch.scientific-python.org
  • [x] remove website from netlify @jarrodmillman
• [x] Update SPEC text @jarrodmillman #307

[MridulS]

I think we can handle this in a new way:

A successful prototype implementation of this SPEC (at least in spirit) is already available inside NetworkX.

NetworkX has developed a dispatching layer which can plug into multiple backends. Currently we have backends which can dispatch to CuGraph, GraphBLAS and a joblib backed parallel implementation of algorithms in NetworkX.

One of the goals here is to provide drop in replacement for old code written with NetworkX. Users should be able to set a config option/env variable and dispatch their code to different backends. These backends could be hardware specific ones, reimplementations in other languages (hello rust!) or using a totally new data structure (GraphBLAS in the case of NetworkX).

On the NetworkX side we are still ironing out more details, and we are still missing out on a detailed spec (or SPEC). I think other projects in the scientific python ecosystem could also benefit from some kind of dispatching along these lines. There is some progress towards creating an engine API in scikit-learn which follows similar rational.

Getting a SPEC together with all the experiments across the ecosystem could be a fruitful task. Maybe this SPEC could be more of an informational document about various efforts across the ecosystem and we can extract the common bits to form some recommendations?

[rgommers]

That sounds like a great idea @MridulS. It'd be useful to have an overview of which projects are trying what, and some learnings. It's still early days in a way, but hopefully at some point one or a couple of patterns appear that can be adopted by others.