Repository navigation
getters for SpatialData format (version) - #288
Conversation
|
|
||
| #' @export | ||
| #' @rdname format | ||
| setMethod("format", "SpatialDataAttrs", \(x) x$spatialdata_attrs$version) |
There was a problem hiding this comment.
why is the function called "format" and not "version"? I find "format" confusing, no? Isn't the "format" "as spatialdata .Zarr store"?
There was a problem hiding this comment.
great question, I am also confused about this ... zarr has formats, but not versions (even though @Bisaloo calls them versions).
https://zarr.readthedocs.io/en/stable/api/zarr/functions/create/#zarr.create
https://huber-group-embl.github.io/Rarr/reference/write_zarr_array.html
@LucaMarconato also uses format and version interchangeably.
https://github.com/scverse/spatialdata/blob/main/src/spatialdata/_io/format.py
I am neutral, I can also call it version, but lets talk about it first.
There was a problem hiding this comment.
It is my understanding that Zarr, OME-Zarr and SD use formats, and those formats have versions.
Check the arguments in SpatialData.write. It is referred to as a format, not version:
https://spatialdata.scverse.org/en/stable/api/SpatialData.html#spatialdata.SpatialData.write
There was a problem hiding this comment.
I thought about this a little bit and decided to go with version. I think the use of word format is quite inaccurate in both anndata and zarr-python.
https://anndata.readthedocs.io/en/stable/generated/anndata.settings.html#anndata.settings.zarr_write_format
That the 2 or 3 are versions of the format but not formats themselves, even though zarr_format replaced zarr_version to avoid confusion with the library version.
https://zarr.readthedocs.io/en/latest/user-guide/v3_migration/#miscellaneous
Thus version(sd) or version(image(sd)) are more intuitive as in "version of format of image data"
There was a problem hiding this comment.
I see format as a shorthand for "version of the format". I have no strong opinions on the naming here.
There was a problem hiding this comment.
But, useful thing, with the help of @jan-glx we simplified the versioning of SpatialData stores by introducing a global "Storage Format" versioning, which is bumped whenever any of the version of the elements or SpatialData container is bumped. On top of this we have now a table that clarify the relationship with also the Zarr format versions, OME-Zarr format versions, software versions, etc. We have a draft in spatialdata-spec (@Artur-man saw already). The code does not write or read this version string yet, but we'll get there.
There was a problem hiding this comment.
I'll let you know when we are done with the draft and the improved versioning system can be translated into code.
There was a problem hiding this comment.
ah thanks, I will try to go with version for now, but I am consulting with Herve Pages before pushing since there are functions/variables named version. If he has strong opinions against, we can go with format.
The function is mostly used for internal purposes anyway. I do not expect people to follow this complex versioning schema.
|
This is how benchmark results would change (along with a 95% confidence interval in relative change) if 360c6dc is merged into devel:
|
|
I have realised that |
|
This is how benchmark results would change (along with a 95% confidence interval in relative change) if 5699a41 is merged into devel:
|
|
I will merge this for now but we can change the name of function any time. |
Related to #115.