Spin off read/write into it's own package?

As we are refactoring scvi, I’m wondering what the utility would be to spin off the i/o part of scanpy into it’s own lightweight package that’s more general for reading single cell pipeline outputs into anndata. For example, we’d like to use the scanpy read from 10x/visium functions, but don’t necessarily want to have scanpy be a full requirement. It’s also a bit confusing why something like read_umi_tools is in anndata but not read_10x_h5. The same goes for loom to some extent. I could imagine either moving such functionality to anndata or a standalone package that could be expanded to include support for other technologies like scATAC-seq.

This overall could be a big benefit to methods developers who would like to build on anndata.

[adamgayoso]

it kind of is imho, it’s all about having whatever data there is in an anndata/mudata shape. I must say that I’d also think plotting could be it’s own separate package but it would probably require a lot of refactoring across packages (thinking about duplication of scanpy/scvelo code)

@giovp and I are synced on these ideas 😃

[adamgayoso]

agree with @grst – also:

I think if we are going to say “here is the way to represent this kind of data” we shouldn’t just set that to be whatever we do currently and call it a standard.

I mean this is what we are currently doing explicitly, it’s just scattered across a few packages.

We really need to fill the current gap in accessibility. The first hit below takes me to a package that doesn’t have functioning API documentation (while it might work it’s not clear if I don’t know what I’m doing).