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/issues/4840#issuecomment-766198081,https://api.github.com/repos/pydata/xarray/issues/4840,766198081,MDEyOklzc3VlQ29tbWVudDc2NjE5ODA4MQ==,11861183,2021-01-23T23:22:11Z,2021-01-23T23:23:41Z,NONE,"Update: after diving into the way the source code works, it seems group information would actually have to get loaded on the backend loaders; this is a pretty deep code change.  The minimal diff seems like it would be to load the group names, then add to the global attrs dictionary `{""groups"": ""group1, group2, ...""}`.  This way, they would automagically propagate all the way through the codebase to the `__repr__` call and show up in the output string.  Of course, it's a little clugey, because the names of the groups aren't _really_ an attribute of the underlying file.  And if there's already an attribute named 'groups'?  Tricky, not sure what the optimal resolution to that is; probably just don't overwrite it and do nothing.  But the alternative is creating a representation for ""groups"" alongside ""dimensions"", ""coordinates"", ""data variables"", and ""attributes"", and adding machinery for these throughout the code base, changing method signatures, etc, which is really more moving in the direction of Datasets actually supporting groups, which is a whole different undertaking.  This is just supposed to be a bit more visibility into the underlying netcdf file.  Unsure if this moderate level of cluge is acceptable or not though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,792651098