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/2844#issuecomment-778632780,https://api.github.com/repos/pydata/xarray/issues/2844,778632780,MDEyOklzc3VlQ29tbWVudDc3ODYzMjc4MA==,2448579,2021-02-13T15:17:21Z,2021-02-13T15:17:21Z,MEMBER,Great I'll merge before the next release if no one else has comments. Thanks @DWesl ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-777487024,https://api.github.com/repos/pydata/xarray/issues/2844,777487024,MDEyOklzc3VlQ29tbWVudDc3NzQ4NzAyNA==,2448579,2021-02-11T14:12:04Z,2021-02-11T14:12:04Z,MEMBER,"> One option is to change decode_coords from bool to Union[bool, str] and allow decode_coords to be either ""all"" (this PR) or ""coordinates"", or True ( == ""coordinates"", backwards compatible). I can bring this up at the next dev meeting.

Updated to implement this proposal after getting OK at the previous meeting.

@DWesl can you take a look at the most recent changes please?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-762899193,https://api.github.com/repos/pydata/xarray/issues/2844,762899193,MDEyOklzc3VlQ29tbWVudDc2Mjg5OTE5Mw==,2448579,2021-01-19T15:03:02Z,2021-01-19T15:03:02Z,MEMBER,"> there were some substantial concerns about backwards compatibility 

:( yes this is currently backward incompatible (so the next release will bump major version). There's reluctance to add yet another `decode_*` kwarg to `open_dataset`, and also reluctance to issue a warning saying that the behaviour of `decode_coords` will change in a future version (since this would be very common).

One option is to change `decode_coords` from `bool` to `Union[bool, str]` and allow `decode_coords` to be either `""all""` (this PR) or `""coordinates""`, or `True` ( == `""coordinates""`, backwards compatible). I can bring this up at the next dev meeting.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-674158261,https://api.github.com/repos/pydata/xarray/issues/2844,674158261,MDEyOklzc3VlQ29tbWVudDY3NDE1ODI2MQ==,2448579,2020-08-14T16:33:31Z,2020-08-14T16:33:31Z,MEMBER,"I think it's OK if we skip `ancillary_variables`, the CF data model does not map perfectly to xarray's data model so this kind of annoyance will always be present. Also thanks @DocOtak for that pathological example :D (now I know what those mathematicians talk about)

> A method or addition to __getitem__ on the accessor returning a Dataset with the linked variables include

This has already been implemented though it could use a lot more testing: https://cf-xarray.readthedocs.io/en/latest/examples/introduction.html#Feature:-Accessing-variables-by-standard-names","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-670728389,https://api.github.com/repos/pydata/xarray/issues/2844,670728389,MDEyOklzc3VlQ29tbWVudDY3MDcyODM4OQ==,2448579,2020-08-07T21:56:29Z,2020-08-07T21:56:29Z,MEMBER,"@DWesl can you put delete the ""bounds"" attribute and send in a PR to xarray-data?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-644407583,https://api.github.com/repos/pydata/xarray/issues/2844,644407583,MDEyOklzc3VlQ29tbWVudDY0NDQwNzU4Mw==,2448579,2020-06-15T21:47:08Z,2020-06-15T21:47:08Z,MEMBER,"Hi @DWesl . I sincerely apologize for not responding earlier.

Reading over this thread again, I think I agree with @shoyer these should live in `encoding`, because we've technically ""decoded"" the attribute and converted these variables to coords.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-596954223,https://api.github.com/repos/pydata/xarray/issues/2844,596954223,MDEyOklzc3VlQ29tbWVudDU5Njk1NDIyMw==,2448579,2020-03-10T08:03:37Z,2020-03-10T08:03:37Z,MEMBER,"My preference is for attrs but someone else should weigh in. cc @pydata/xarray 

Maybe @dopplershift , as MetPy maintainer has thoughts on this matter?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-497760666,https://api.github.com/repos/pydata/xarray/issues/2844,497760666,MDEyOklzc3VlQ29tbWVudDQ5Nzc2MDY2Ng==,2448579,2019-05-31T15:50:28Z,2019-05-31T15:50:28Z,MEMBER,"It isn't just MetPy though. I'm sure there's existing code relying on adding `grid_mapping` and `bounds` to `attrs` in order to write CF-compliant files. So there's a (potentially big) backward compatibility issue. This becomes worse if in the future we keep interpreting more CF attributes and moving them to `encoding` :/.

> Since I'm doing this primarily to get grid_mapping and bounds variables out of ds.data_vars.

I'm +1 on this but I wonder whether saving them in `attrs` and using that information when encoding coordinates would be the more pragmatic choice. 

We could define `encoding` as containing a specified set of CF attributes that control on-disk representation such as `units`, `scale_factor`, `contiguous` etc. and leaving everything else in `attrs`. A full list of attributes that belong in `encoding` could be in the docs so that downstream packages can fully depend on this behaviour.

Currently I see `coordinates` is interpreted and moved to `encoding`. In the above proposal, this would be left in `attrs` but its value would still be interpreted if `decode_coords=True`.

What do you think?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093
https://github.com/pydata/xarray/pull/2844#issuecomment-497553898,https://api.github.com/repos/pydata/xarray/issues/2844,497553898,MDEyOklzc3VlQ29tbWVudDQ5NzU1Mzg5OA==,2448579,2019-05-31T02:37:31Z,2019-05-31T02:37:31Z,MEMBER,I'm a little confused on why these are in encoding and not in attrs.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,424265093