MuData API considerations about scirpy

[grst]

@gtca, would be great to get your input on this!

[gtca]

Hey!

I'll try to briefly comment on this below (and I'm happy to catch up later to discuss it further).

API consideration for unimodal data

1. For a function that only operates on the AIRR data, what is the preferred option to interact with mudata?

The way it is addressed in muon for example is supporting both. Directly referring to the mdata['airr'] AnnData object might be cleaner / simpler — but then in many cases it would be enough to write ir.tl.chain_qc(mdata) due to the defaults, which is nice (will require having an additional parameter though).

2. Should a function that only operates on the AIRR data add columns to mdata or adata?

I would say adata. And calling the .update_obs() inside might have some unintended consequences — e.g. if this "synchronisation" hasn't been performed before, more things will happen than just copying one column. (My current thinking is that only functions that are going to break without .update() can run it internally with some log trace.) Plus we might also reconsider in future if we should always copy the columns with updates by default.

3. Use muon for plotting or scanpy?

I think mu.pl starts being very useful when information from different modalities is used. I am not sure if this is makes more sense semantically to have X_umap in mdata['gex'].obsm or in mdata.obsm but generally, mu.pl.embedding(mdata, basis="gex:X_umap", color="gex:cluster") should address this point.

For the last point in the original post, I think the proposed solution is a reasonable one.

Exciting to see this taking shape!