implementation and default behaviour of readTable

[Artur-man]

Here, readTable incorporates basilisk/reticulate to read AnnData from a zarr group.
https://github.com/HelenaLC/SpatialData/blob/819c886135a0e7d8fdb35a5bb3828857f730a882/R/read.R#L149C1-L164C2

readTable <- function(path) {
    proc <- basiliskStart(.env)
    on.exit(basiliskStop(proc))
    sce <- basiliskRun(proc, function(zarr) {
        # return value MUST be a pure R object,
        # i.e., no reticulate Python objects
        # or pointers to shared memory
        ad <- import("anndata")
        obj <- ad$read_zarr(zarr)
        sce <- AnnData2SCE(obj)
    }, zarr=path)
    za <- fromJSON(file.path(path, ".zattrs"))
    int_metadata(sce)$zattrs <- za
    metadata(sce) <- list()
    return(sce)
}

Perhaps replace the need for basilisk with anndataR ? ... since I dont know if anndata (CRAN) is still maintained.

As for anndataR's ability to read objects from zarr stores, @keller-mark was recently working on extending anndataR readers to zarr (scverse/anndataR#91 (comment)).

[HelenaLC]

Hi & thanks for this! I'm aware of basilisk (or any non-native R solution) being suboptimal. In fact, anndataR and SpatialData repos were conceived on the the same day, in the same room. Then, initial efforts were made to implement an R6 class for AnnData in R and support for reading/writing .h5ad. Once a stable and maintaining solution becomes available to read/write .zarr, basilisk will go in favor of it. On another note: storing tables in .zarr is not part of any standard FF, and may thus also be subject to change. We just have to wait and see at this point how things develop, and the current solution works/is compatible with SpatialData's current way of doing things in Python.