You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could make an entrypoint system for virtualizarr, in addition to plugging in to xarray's backend entrypoint system. That would allow this syntax for creating virtual xr.Dataset objects containing ManifestArrays, e.g.
This would allow users to freely create their own virtual readers / metadata parsers (whatever we call them #239) to deal with their own gnarly file formats, without requiring upstream contributions. This model for extendability has worked very well for xarray, and it's completely analogous to the problem we have here.
If we combined this with #35, we would then have a virtualizarr xarray backend entrypoint, which calls out to specific virtualizarr readers via another entrypoint. That would allow this syntax.
We could make an entrypoint system for virtualizarr, in addition to plugging in to xarray's backend entrypoint system. That would allow this syntax for creating virtual
xr.Dataset
objects containingManifestArrays
, e.g.(as suggested in #238)
This would allow users to freely create their own virtual readers / metadata parsers (whatever we call them #239) to deal with their own gnarly file formats, without requiring upstream contributions. This model for extendability has worked very well for xarray, and it's completely analogous to the problem we have here.
If we combined this with #35, we would then have a virtualizarr xarray backend entrypoint, which calls out to specific virtualizarr readers via another entrypoint. That would allow this syntax.
I think we should make the entrypoint system in virtualizarr first before we decide if entrypoints calling entrypoints is actually a good idea... 🐶
cc @ayushnag
The text was updated successfully, but these errors were encountered: