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 2234142680,PR_kwDOAMm_X85sK0g8,8923,"`""source""` encoding for datasets opened from `fsspec` objects",14808389,open,0,,,5,2024-04-09T19:12:45Z,2024-04-23T16:54:09Z,,MEMBER,,0,pydata/xarray/pulls/8923,"When opening files from path-like objects (`str`, `pathlib.Path`), the backend machinery (`_dataset_from_backend_dataset`) sets the `""source""` encoding. This is useful if we need the original path for additional processing, like writing to a similarly named file, or to extract additional metadata. This would be useful as well when using `fsspec` to open remote files. In this PR, I'm extracting the `path` attribute that most `fsspec` objects have to set that value. I've considered using `isinstance` checks instead of the `getattr`-with-default, but the list of potential classes is too big to be practical (at least 4 classes just within `fsspec` itself). If this sounds like a good idea, I'll update the documentation of the `""source""` encoding to mention this feature. - [x] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8923/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 683142059,MDU6SXNzdWU2ODMxNDIwNTk=,4361,restructure the contributing guide,14808389,open,0,,,5,2020-08-20T22:51:39Z,2023-03-31T17:39:00Z,,MEMBER,,,,"From #4355 @max-sixty: > Stepping back on the contributing doc — I admit I haven't look at it in a while — I wonder whether we can slim it down a bit, for example by linking to other docs for generic tooling — I imagine we're unlikely to have the best docs on working with GH, for example. Or referencing our PR template rather than the (now out-of-date) PR checklist. We could also add a docstring guide since the `numpydoc` guide does not cover every little detail (for example, `default` notation, type spec vs. type hint, space before the colon separating parameter names from types, no colon for parameters without types, etc.)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4361/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue 1534634670,PR_kwDOAMm_X85Hc1wx,7442,update the docs environment,14808389,closed,0,,,5,2023-01-16T09:58:43Z,2023-03-03T10:17:14Z,2023-03-03T10:14:13Z,MEMBER,,0,pydata/xarray/pulls/7442,"Most notably: - bump `python` to `3.10` - bump `sphinx` to at least `5.0` - remove the `pydata-sphinx-theme` pin: `sphinx-book-theme` pins to a exact minor version so pinning as well does not change anything - xref https://github.com/executablebooks/sphinx-book-theme/issues/686 ~Edit: it seems this is blocked by `sphinx-book-theme` pinning `sphinx` to `>=3,<5`. They already changed the pin, we're just waiting on a release~","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7442/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1519058102,PR_kwDOAMm_X85GoVw9,7415,install `numbagg` from `conda-forge`,14808389,closed,0,,,5,2023-01-04T14:17:44Z,2023-01-20T19:46:46Z,2023-01-20T19:46:43Z,MEMBER,,0,pydata/xarray/pulls/7415,"It seems there is a `numbagg` package on `conda-forge` now. Not sure what to do about the `min-all-deps` CI, but given that the most recent version of `numbagg` happened more than 12 months ago (more than 18 months, even) maybe we can just bump it to the version on `conda-forge`?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7415/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1404894283,PR_kwDOAMm_X85AlZGn,7153,use a hook to synchronize the versions of `black`,14808389,closed,0,,,5,2022-10-11T16:07:05Z,2022-10-12T08:00:10Z,2022-10-12T08:00:07Z,MEMBER,,0,pydata/xarray/pulls/7153,"We started to pin the version of `black` used in the environment of `blackdoc`, but the version becomes out-of-date pretty quickly. The new hook I'm adding here is still experimental, but pretty limited in what it can destroy (the `pre-commit` configuration) so for now we can just review any new autoupdate PRs from the `pre-commit-ci` a bit more thoroughly.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7153/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 628436420,MDU6SXNzdWU2Mjg0MzY0MjA=,4116,xarray ufuncs,14808389,closed,0,,,5,2020-06-01T13:25:54Z,2022-04-19T03:26:53Z,2022-04-19T03:26:53Z,MEMBER,,,,"The documentation warns that the universal functions in `xarray.ufuncs` should not be used unless compatibility with `numpy < 1.13` is required. Since we only support `numpy >= 1.15`: is it time to remove that (already deprecated) module? Since there are also functions that are not true ufuncs (e.g. `np.angle` and `np.median`) and need `__array_function__` (or something similar, see #3917), we could also keep those and just remove the ones that are dispatched using `__array_ufunc__`.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4116/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 789106802,MDU6SXNzdWU3ODkxMDY4MDI=,4825,clean up the API for renaming and changing dimensions / coordinates,14808389,open,0,,,5,2021-01-19T15:11:55Z,2021-09-10T15:04:14Z,,MEMBER,,,,"From #4108: I wonder if it would be better to first ""reorganize"" all of the existing functions: we currently have `rename` (and `Dataset.rename_dims` / `Dataset.rename_vars`), `set_coords`, `reset_coords`, `set_index`, `reset_index` and `swap_dims`, which overlap partially. For example, the code sample from #4417 works if instead of ```python ds = ds.rename(b='x') ds = ds.set_coords('x') ``` we use ```python ds = ds.set_index(x=""b"") ``` and something similar for the code sample in #4107. I believe we currently have these use cases (not sure if that list is complete, though): - rename a `DataArray` → `rename` - rename a existing variable to a name that is not yet in the object → `rename` / `Dataset.rename_vars` / `Dataset.rename_dims` - convert a data variable to a coordinate (not a dimension coordinate) → `set_coords` - convert a coordinate (not a dimension coordinate) to a data variable → `reset_coords` - swap a existing dimension coordinate with a coordinate (which may not exist) and rename the dimension → `swap_dims` - use a existing coordinate / data variable as a dimension coordinate (do not rename the dimension) → `set_index` - stop using a coordinate as dimension coordinate and append `_` to its name (do not rename the dimension) → `reset_index` - use two existing coordinates / data variables as a MultiIndex → `set_index` - stop using a MultiIndex as a dimension coordinate and use its levels as coordinates → `reset_index` Sometimes, some of these can be emulated by combinations of others, for example: ```python # x is a dimension without coordinates assert_identical(ds.set_index({""x"": ""b""}), ds.swap_dims({""x"": ""b""}).rename({""b"": ""x""})) assert_identical(ds.swap_dims({""x"": ""b""}), ds.set_index({""x"": ""b""}).rename({""x"": ""b""})) ``` and, with this PR: ```python assert_identical(ds.set_index({""x"": ""b""}), ds.set_coords(""b"").rename({""b"": ""x""})) assert_identical(ds.swap_dims({""x"": ""b""}), ds.rename({""b"": ""x""})) ``` which means that it would increase the overlap of `rename`, `set_index`, and `swap_dims`. In any case I think we should add a guide which explains which method to pick in which situation (or extend `howdoi`). _Originally posted by @keewis in https://github.com/pydata/xarray/issues/4108#issuecomment-761907785_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4825/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue 818051289,MDExOlB1bGxSZXF1ZXN0NTgxNDE3NTg0,4971,add a combine_attrs option to open_mfdataset,14808389,closed,0,,,5,2021-02-27T23:05:01Z,2021-04-03T15:43:17Z,2021-04-03T15:43:14Z,MEMBER,,0,pydata/xarray/pulls/4971,"In order to fix the failing tests in #4902 we need to expose `combine_attrs` to be able to properly construct the expected result (to be passed through to the combine function). This overlaps with the fallback of the `attrs_file` code, which I removed for now. Maybe `combine_attrs=""override""` would be better? - [x] Tests added - [x] Passes `pre-commit run --all-files` - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4971/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 791277757,MDU6SXNzdWU3OTEyNzc3NTc=,4837,expose _to_temp_dataset / _from_temp_dataset as semi-public API?,14808389,open,0,,,5,2021-01-21T16:11:32Z,2021-01-22T02:07:08Z,,MEMBER,,,,"When writing accessors which behave the same for both `Dataset` and `DataArray`, it would be incredibly useful to be able to use `DataArray._to_temp_dataset` / `DataArray._from_temp_dataset` to deduplicate code. Is it safe to use those in external packages (like `pint-xarray`)? Otherwise I guess it would be possible to use ```python name = da.name if da.name is None else ""__temp"" temp_ds = da.to_dataset(name=name) new_da = temp_ds[name] if da.name is None: new_da = new_da.rename(da.name) assert_identical(da, new_da) ``` but that seems less efficient.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4837/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue 784628736,MDU6SXNzdWU3ODQ2Mjg3MzY=,4801,scheduled upstream-dev CI is skipped,14808389,closed,0,,,5,2021-01-12T22:08:19Z,2021-01-14T00:09:43Z,2021-01-13T21:35:44Z,MEMBER,,,,"The scheduled CI is being skipped since about 6 days ago (which means this is probably due to the merge of #4729, see [this run](https://github.com/pydata/xarray/actions/runs/464816162) before the merge and [this run](https://github.com/pydata/xarray/actions/runs/467551905) after the merge). This is really strange because `workflow_dispatch` events (for which the CI detection job is also skipped) still work perfectly fine. Edit: it seems to be because of https://github.com/pydata/xarray/blob/f52a95cbe694336fe47bc5a42c713bee8ad74d64/.github/workflows/upstream-dev-ci.yaml#L34-L37 if I remove that the scheduled CI runs. cc @andersy005","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4801/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 638211949,MDU6SXNzdWU2MzgyMTE5NDk=,4152,signature in accessor methods,14808389,closed,0,,,5,2020-06-13T18:49:16Z,2020-09-06T23:05:04Z,2020-09-06T23:05:04Z,MEMBER,,,,"With the merge of #3988 we're now properly documenting the `str`, `dt` and `plot` accessors, but the signatures of the plotting methods are missing a few parameters. For example, `DataArray.plot.contour` is missing the parameter `x` (it's properly documented in the parameters section, though). Also, we need to remove the `str` and `dt` accessors from `Computing` and try to figure out how to fix the summary of `DataArray.plot` (the plotting method).","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4152/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 663977922,MDExOlB1bGxSZXF1ZXN0NDU1Mjk1NTcw,4254,fix the RTD timeouts,14808389,closed,0,,,5,2020-07-22T18:56:16Z,2020-07-23T16:10:55Z,2020-07-22T21:17:59Z,MEMBER,,0,pydata/xarray/pulls/4254,"This attempts to fix the RTD timeouts. I think these are due to a warning from `matplotlib`, which we can probably just ignore for now. - [x] attempts to close #4249 - [ ] Tests added - [x] Passes `isort . && black . && mypy . && flake8` - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [ ] New functions/methods are listed in `api.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4254/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 600641276,MDExOlB1bGxSZXF1ZXN0NDA0MDMzMjk0,3975,pint support for Dataset,14808389,closed,0,,,5,2020-04-15T23:11:15Z,2020-06-17T20:40:12Z,2020-06-17T20:40:07Z,MEMBER,,0,pydata/xarray/pulls/3975,"This is part of the effort to add support for `pint` (see #3594) to `Dataset` objects (although it will probably be a test-only PR, just like #3643). - [x] Tests added - [x] Passes `isort -rc . && black . && mypy . && flake8` - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API The list of failing tests from #3594: * Dataset methods - `__init__`: Needs unit support in IndexVariable, and merge does not work yet (test bug is also possible) - aggregation: `xarray` does not implement `__array_function__` (see #3917) - `rank`: depends on `bottleneck` and thus only works with `numpy.array` - `ffill`, `bfill`: uses `bottleneck` - `interpolate_na`: uses `numpy.vectorize`, which does not support NEP-18, yet - `equals`, `identical`: works (but no units / unit checking in `IndexVariable`) - `broadcast_like`: works (but no units / unit checking in `IndexVariable`) - `to_stacked_array`: no units in `IndexVariable` - `sel`, `loc`: no units in `IndexVariable` - `interp`, `reindex`: partially blocked by `IndexVariable`. `reindex` works with units in `data`, but `interp` uses `scipy` - `interp_like`, `reindex_like`: same as `interp` / `reindex` - `quantile`: works, but needs `pint` >= 0.12 - `groupby_bins`: needs `pint` >= 0.12 (for `isclose`) - `rolling`: uses `numpy.lib.stride_tricks.as_strided` - `rolling_exp`: uses `numbagg` (supports NEP-18, but `pint` doesn't support its functions)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3975/reactions"", ""total_count"": 2, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 2, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 636225143,MDExOlB1bGxSZXF1ZXN0NDMyNDM3Njc5,4138,Fix the upstream-dev pandas build failure,14808389,closed,0,,,5,2020-06-10T12:58:29Z,2020-06-11T10:10:50Z,2020-06-11T02:14:49Z,MEMBER,,0,pydata/xarray/pulls/4138,"As pointed out by @TomAugspurger in https://github.com/pydata/xarray/issues/4133#issuecomment-641332231, there are pre-built nightly wheels for `numpy`, `scipy` and `pandas` in the [scipy-wheels-nightly repository](https://anaconda.org/scipy-wheels-nightly/). Not sure how frequently these are updated, though, at least the `numpy` wheel doesn't really seem to be built daily. - [x] Closes #4133 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4138/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 543276677,MDExOlB1bGxSZXF1ZXN0MzU3NTc5ODQ5,3654,Tests for variables with units,14808389,closed,0,,,5,2019-12-28T20:21:06Z,2020-01-15T16:59:00Z,2020-01-15T16:53:01Z,MEMBER,,0,pydata/xarray/pulls/3654,"As promised in #3493, this adds integration tests for units. I'm doing this now rather than later since I encountered a few cases in #3643 where a increased test coverage for variables would have been helpful. - [x] Tests added - [x] Passes `black . && mypy . && flake8` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3654/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 517195073,MDU6SXNzdWU1MTcxOTUwNzM=,3483,assign_coords with mixed DataArray / array args removes coords,14808389,open,0,,,5,2019-11-04T14:38:40Z,2019-11-07T15:46:15Z,,MEMBER,,,,"I'm not sure if using `assign_coords` to overwrite the data of coords is the best way to do so, but using mixed args (on current master) turns out to have surprising results: ```python >>> obj = xr.DataArray( ... data=[6, 3, 4, 6], ... coords={""x"": list(""abcd""), ""y"": (""x"", range(4))}, ... dims=""x"", ... ) >>> obj array([6, 3, 4, 6]) Coordinates: * x (x) >> # works as expected >>> obj.assign_coords(coords={""x"": list(""efgh""), ""y"": (""x"", [0, 2, 4, 6])}) array([6, 3, 4, 6]) Coordinates: * x (x) >> # works, too (same as .data / .values) >>> obj.assign_coords(coords={ ... ""x"": obj.x.copy(data=list(""efgh"")).variable, ... ""y"": (""x"", [0, 2, 4, 6]), ... }) array([6, 3, 4, 6]) Coordinates: * x (x) >> # this drops ""y"" >>> obj.assign_coords(coords={ ... ""x"": obj.x.copy(data=list(""efgh"")), ... ""y"": (""x"", [0, 2, 4, 6]), ... }) array([6, 3, 4, 6]) Coordinates: * x (x) >> obj.assign_coords(x=list(""efgh""), y=obj.y * 2) xarray.core.merge.MergeError: conflicting values for index 'x' on objects to be combined: first value: Index(['e', 'f', 'g', 'h'], dtype='object', name='x') second value: Index(['a', 'b', 'c', 'd'], dtype='object', name='x') ``` I would expect the result to be the same regardless of the type of the new coords. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3483/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,issue