Switch t-SNE in scanpy to openTSNE

I'm not sure what t-SNE implementation is currently used in scanpy, but would it make sense to switch it to openTSNE? It's a Cython re-implementation of FIt-SNE, it's available on conda and should be very easy to depend on.

As far as I understand the scanpy architecture, it builds a kNN graph and then runs downstream analysis (like UMAP or Louvain) on this kNN graph. Is that right? I suppose this is currently not implemented for t-SNE? With openTSNE it'd be easy to use the pre-built kNN graph and run t-SNE directly on that.

Also, the default parameters of t-SNE in scanpy could IMHO be improved, see https://www.nature.com/articles/s41467-019-13056-x. Some of these recommendations (learning rate, initialization) are now default in openTSNE.

There are some open issues at scanpy related to t-SNE such as https://github.com/theislab/scanpy/issues/1150 and https://github.com/theislab/scanpy/issues/996 but I think this suggestion would supersede them. We had a brief discussion of this at openTSNE here https://github.com/pavlin-policar/openTSNE/issues/102.

I can see four somewhat separate suggestions:

1. switch scanpy to using openTSNE for tSNE, using already constructed kNN graph
2. add tSNE support for ingest using openTSNE functionality.
3. change default tSNE parameters (n_iter, learning rate, initialization) following openTSNE defaults.
4. add some tSNE "recipes" based on https://www.nature.com/articles/s41467-019-13056-x

What of this, if any, makes sense from the scanpy point of view?

No files or tests are named. First inspect Scanpy's current t-SNE entry point, kNN graph handling, and ingest support, then review issues 1150 and 996 plus the linked openTSNE discussion. Done would require a decided scope among the four proposed changes and an agreed implementation plan.