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
2194953062,PR_kwDOAMm_X85qFqp1,8854,array api-related upstream-dev failures,14808389,open,0,,,15,2024-03-19T13:17:09Z,2024-05-03T22:46:41Z,,MEMBER,,0,pydata/xarray/pulls/8854,"- [x] towards #8844

This ""fixes"" the upstream-dev failures related to the removal of `numpy.array_api`. There are a couple of open questions, though:
- `array-api-strict` is not installed by default, so `namedarray` would get a new dependency. Not sure how to deal with that – as far as I can tell, `numpy.array_api` was not supposed to be used that way, so maybe we need to use `array-api-compat` instead? What do you think, @andersy005, @Illviljan?
- `array-api-strict` does not define `Array.nbytes` (causing a funny exception that wrongly claims `DataArray` does not define `nbytes`)
- `array-api-strict` has a different `DType` class, which makes it tricky to work with both `numpy` dtypes and said dtype class in the same code. In particular, if I understand correctly we're supposed to check dtypes using `isdtype`, but `numpy.isdtype` will only exist in `numpy>=2`, `array-api-strict`'s version does not define datetime / string / object dtypes, and `numpy.issubdtype` does not work with the non-`numpy` dtype class). So maybe we need to use `array-api-compat` internally?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8854/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
2269295936,PR_kwDOAMm_X85uBwtv,8983,fixes for the `pint` tests,14808389,open,0,,,0,2024-04-29T15:09:28Z,2024-05-03T18:30:06Z,,MEMBER,,0,pydata/xarray/pulls/8983,"This removes the use of the deprecated `numpy.core._exceptions.UFuncError` (and multiplication as a way to attach units), and makes sure we run the `pint` tests in the upstream-dev CI again.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8983/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
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.

<!-- Feel free to remove check-list items aren't relevant to your change -->

- [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
2241492018,PR_kwDOAMm_X85skF_A,8937,drop support for `python=3.9`,14808389,open,0,,,3,2024-04-13T10:18:04Z,2024-04-15T15:07:39Z,,MEMBER,,0,pydata/xarray/pulls/8937,"According to our policy (and NEP-29) we can drop support for `python=3.9` since about a week ago. Interestingly, SPEC0 says we could have started doing this about half a year ago (Q4 2023).

We could delay this until we have a release that is compatible with `numpy>=2.0`, though (`numpy>=2.1` will drop support for `python=3.9`).

- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8937/reactions"", ""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
818059250,MDExOlB1bGxSZXF1ZXN0NTgxNDIzNTIx,4972,Automatic duck array testing - reductions,14808389,open,0,,,23,2021-02-27T23:57:23Z,2022-08-16T13:47:05Z,,MEMBER,,1,pydata/xarray/pulls/4972,"This is the first of a series of PRs to add a framework to make testing the integration of duck arrays as simple as possible. It uses `hypothesis` for increased coverage and maintainability.

- [x] Tests added
- [x] Passes `pre-commit run --all-files`
- [ ] 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/4972/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
597566530,MDExOlB1bGxSZXF1ZXN0NDAxNjU2MTc1,3960,examples for special methods on accessors,14808389,open,0,,,6,2020-04-09T21:34:30Z,2022-06-09T14:50:17Z,,MEMBER,,0,pydata/xarray/pulls/3960,"This starts adding the parametrized accessor examples from #3829 to the accessor documentation as suggested by @jhamman. Since then the `weighted` methods have been added, though, so I'd like to use a different example instead (ideas welcome).

Also, this feature can be abused to add functions to the main `DataArray` / `Dataset` namespace (by registering a function with the `register_*_accessor` decorators, see the second example). Is this something we want to explicitly discourage?

(~When trying to build the docs locally, sphinx keeps complaining about a code block without code. Not sure what that is about~ seems the `ipython` directive does not allow more than one expression, so I used `code` instead)

 - [x] Closes #3829
 - [x] Passes `isort -rc . && black . && mypy . && flake8`
 - [x] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/3960/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
801728730,MDExOlB1bGxSZXF1ZXN0NTY3OTkzOTI3,4863,apply to dataset,14808389,open,0,,,14,2021-02-05T00:05:22Z,2022-06-09T14:50:17Z,,MEMBER,,0,pydata/xarray/pulls/4863,"as discussed in #4837, this adds a method that applies a function to a `DataArray` by first converting it to a temporary dataset using `_to_temp_dataset`, applies the function and converts it back. I'm not really happy with the name but I can't find a better one.

This function is really similar to `pipe`, so I guess a keyword argument to pipe would work, too. The disadvantage of that is that `pipe` passes all kwargs to the passed function, which means we would shadow a specific kwarg.

- [x] Closes #4837
- [x] Tests added
- [x] Passes `pre-commit run --all-files`
- [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
- [x] New functions/methods are listed in `api.rst`
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/4863/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull
959063390,MDExOlB1bGxSZXF1ZXN0NzAyMjM0ODc1,5668,create the context objects passed to custom `combine_attrs` functions,14808389,open,0,,,1,2021-08-03T12:24:50Z,2022-06-09T14:50:16Z,,MEMBER,,0,pydata/xarray/pulls/5668,"Follow-up to #4896: this creates the context object in reduce methods and passes it to `merge_attrs`, with more planned.

- [ ] might help with xarray-contrib/cf-xarray#228
- [ ] Tests added
- [x] Passes `pre-commit run --all-files`
- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
- [ ] New functions/methods are listed in `api.rst`

Note that for now this is a bit inconvenient to use for provenance tracking (as discussed in the `cf-xarray` issue) because functions implementing that would still have to deal with merging the `attrs`.
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5668/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull