issue_comments: 598569859
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/pydata/xarray/pull/3858#issuecomment-598569859 | https://api.github.com/repos/pydata/xarray/issues/3858 | 598569859 | MDEyOklzc3VlQ29tbWVudDU5ODU2OTg1OQ== | 2444231 | 2020-03-13T06:21:35Z | 2020-03-13T06:25:43Z | NONE | Yes, I agree. Having a library only depend on the environment is less than optimal to say the least. The main reason behind this was to allow one of the GRB backends to read custom tables. I've already contacted both the cfgrib and PyNIO people to see about changing this to something more flexible. Regarding writing my own utility: I'm afraid this introduces one more hoop for end users to jump through. If I can tell my colleagues "Hey just use Xarray", that normally works pretty well. If I now need to say "Hey, use my own little thing plus Xarray plus ...." (who knows what else) might introduce more friction. However, it's an interesting idea: How challenging would it be to write my own Xarray backend (In this case for GRB files) and include that instead? Would Xarray be open to including a further backend? That would separate the logic into it's own project and if anything breaks, then the Xarray team would have less to worry about and can just refer issues to the backend development team (so, I guess me 😉)... |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
579722569 |