issues

Table actions

3 rows where comments = 7, type = "issue" and user = 1197350 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date), closed_at (date)

state 2

type 1

  • issue · 3 ✖

repo 1

id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
396806015 MDU6SXNzdWUzOTY4MDYwMTU= 2660 DataArrays to/from Zarr Arrays rabernat 1197350 open 0     7 2019-01-08T08:56:05Z 2023-10-27T14:00:20Z   MEMBER      

Right now, open_zarr and Dataset.to_zarr only work with Zarr groups. Zarr Groups can contain multiple Array objects.

It would be nice if we could open Zarr Arrays directly as xarray DataArrays and write xarray DataArrays directly to Zarr Arrays.

However, this might not make sense, because, unlike xarray DataArrays, zarr Arrays can't hold any coordinates.

Just raising this idea for discussion.

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2660/reactions",
    "total_count": 3,
    "+1": 3,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   reopened xarray 13221727 issue
1047608434 I_kwDOAMm_X84-cTxy 5954 Writeable backends via entrypoints rabernat 1197350 open 0     7 2021-11-08T15:47:12Z 2021-11-09T16:28:59Z   MEMBER      

The backend refactor has gone a long way towards making it easier to implement custom backend readers via entry points. However, it is still not clear how to implement a writeable backend from a third party package as an entry point. Some of the reasons for this are:

We should fix this situation! Here are the steps I would take.

  • [ ] Decide on the desired API for writeable backends.
  • [ ] Formalize this in the BackendEntrypoint base class.
  • [ ] Refactor the existing writeable backends (netcdf4-python, h5netcdf, scipy, Zarr) to use this API
  • [ ] Maybe deprecate to_zarr and to_netcdf (or at least refactor to make a shallow call to a generic method)
  • [ ] Encourage third party implementors to try it (e.g. TileDB)
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/5954/reactions",
    "total_count": 1,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 1
}
     xarray 13221727 issue
193657418 MDU6SXNzdWUxOTM2NTc0MTg= 1154 netCDF reading is not prominent in the docs rabernat 1197350 closed 0     7 2016-12-06T01:18:40Z 2019-02-02T06:33:44Z 2019-02-02T06:33:44Z MEMBER      

Just opening an issue to highlight what I think is a problem with the docs.

For me, the primary use of xarray is to read and process existing netCDF data files. @shoyer's popular blog post illustrates this use case extremely well.

However, when I open the docs, I have to dig quite deep before I can see how to read a netCDF file. This could be turning away many potential users. The stuff about netCDF reading is hidden under "Serialization and IO". Many potential users will have no idea what either of these words mean.

IMO the solution to this is to reorganize the docs to make reading netCDF much more prominent and obvious.

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/1154/reactions",
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   completed xarray 13221727 issue

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);