id,node_id,number,state,locked,title,user,body,created_at,updated_at,closed_at,merged_at,merge_commit_sha,assignee,milestone,draft,head,base,author_association,auto_merge,repo,url,merged_by
220706493,MDExOlB1bGxSZXF1ZXN0MjIwNzA2NDkz,2465,closed,0,Add python_requires to setup.py,1828519,"This should assist users using PyPI/pip to install xarray when xarray drops python 2.7 support. The `python_requires` argument is described here:

https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires

Basically, it says what versions of python your package supports. When xarray drops python 2 support and this kwarg gets update it should stop people on python 2 from getting the wrong package.

 - [x] Tests passed (for all non-documentation changes)

",2018-10-05T13:43:06Z,2018-10-06T07:49:08Z,2018-10-06T07:48:58Z,2018-10-06T07:48:58Z,4a7a103204989af7e2b6bc97a4109d81beebd34c,,,0,a771c911a07ff04058d3cc68fa47ab79176eeabd,3cef8d730d5bbd699a393fa15266064ebb9849e2,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/2465,
247899648,MDExOlB1bGxSZXF1ZXN0MjQ3ODk5NjQ4,2715,closed,0,Fix CRS being WKT instead of PROJ.4,1828519,"See https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L7 for the change in rasterio 1.0.14 and my conda-forge issue where I discovered this: https://github.com/conda-forge/gdal-feedstock/issues/262

This was put in a bugfix (micro version number) release of rasterio which made it harder to discover. @sgillies @snowman2 I saw that you brought this up and how it affected xarray (https://rasterio.groups.io/g/dev/message/68). If this pull request is a duplicate of a fix one of you made let me know.

To xarray devs, if I need to make any other changes (whats-new?) also let me know.

 - [ ] Closes #xxxx
 - [ ] Tests added
 - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API
",2019-01-26T16:46:11Z,2019-03-12T18:57:44Z,2019-02-06T16:56:07Z,2019-02-06T16:56:06Z,0c73a380745c4792ab440eb020f78f203897abe5,,,0,4e827b72cc8a0e2adbac650a2b65ce4953baff39,e677b7a0aa344faee3eb407e63422038c2029399,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/2715,
286515468,MDExOlB1bGxSZXF1ZXN0Mjg2NTE1NDY4,3006,closed,0,Fix 'to_masked_array' computing dask arrays twice,1828519,"I ran in to this issue when using `imshow` on a dask-based `DataArray` and dask's `ProgressBar()` context manager. I noticed that when using `my_data_arr.plot.imshow` the dask array was being computed twice. This PR fixes that.

Suggestions for tests and documenting this fix are welcome.

 - [ ] Closes #xxxx
 - [ ] Tests added
 - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API
",2019-06-10T01:33:08Z,2019-06-25T16:56:19Z,2019-06-10T13:25:58Z,2019-06-10T13:25:58Z,adbd59a0498cce298d88d9383837c968bebae538,,,0,c7a81b98bc556569a15ce01aedbd8524ccc06c08,44011c9857b249b65b5f403d2791e198e3d67a87,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/3006,
306491733,MDExOlB1bGxSZXF1ZXN0MzA2NDkxNzMz,3209,closed,0,Add note about accessor instance creation,1828519,"This is an attempt at clarifying accessor docs to help with the confusion I had in #3205. I'm not sure how many other xarray doc pages use `.. note::` but it seemed useable here. I'm not sure this is worth the explanation or if it is worded the best, but thought this could start the discussion.

 - [ ] Closes #3205 
 - [ ] Tests added
 - [ ] Passes `black . && mypy . && flake8`
 - [ ] Fully documented, including `whats-new.rst` for all changes and `api.rst` for new API
",2019-08-12T13:17:13Z,2019-08-14T13:08:54Z,2019-08-14T05:33:49Z,2019-08-14T05:33:48Z,2fdcbb6feccb01a97b8b51160b81e238486fff00,,,0,14dca12191e7ab82a74599e5ae56fbd078a13f0c,b0df4d901ad7625b0ffabc8d85775efaca9d2c2f,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/3209,
1386907083,PR_kwDOAMm_X85SqoXL,7905,open,0,Add '.hdf' extension to 'netcdf4' backend,1828519,"I'm helping @joleenf debug an issue where some old code that uses `xr.open_dataset` no longer works since the introduction of engines or at least as far as we can tell. The main issue is that she's using code that assumes the NetCDF4 C library was compiled with HDF4 support (ex. conda-forge builds with this functionality enabled). So in this case `netCDF4.Dataset(""my_file.hdf"")` can actually read the HDF4 file through the NetCDF4 C library.

However, with `xr.open_dataset(""my_file.hdf"")` will fail because xarray (or rather the netcdf4 engine) doesn't know that it could potentially read HDF4 files. This PR adds the `.hdf` extension to the 'netcdf4' engine to allow this to be automatic without needing `engine='netcdf4'` to be specified.

What do people think? I didn't want to put any more work into this until others weighed in.

- [ ] Closes #xxxx
- [ ] Tests added
- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
- [ ] New functions/methods are listed in `api.rst`
",2023-06-10T00:45:15Z,2023-06-14T15:25:08Z,,,3df1dc60eb0250a11655e15289454b06ba29f86d,,,0,9abc5ba691bd4200cf1561d31cfd78d6434ce684,3459e6fa3c41b9e7b796800682bcf1408467cf1e,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/7905,
1824051470,PR_kwDOAMm_X85suNEO,8946,open,0,Fix upcasting with python builtin numbers and numpy 2,1828519,"See #8402 for more discussion. Bottom line is that numpy 2 changes the rules for casting between two inputs. Due to this and xarray's preference for promoting python scalars to 0d arrays (scalar arrays), xarray objects are being upcast to higher data types when they previously didn't.

I'm mainly opening this PR for further and more detailed discussion.

CC @dcherian

- [ ] Closes #8402
- [ ] Tests added
- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`
- [ ] New functions/methods are listed in `api.rst`
",2024-04-15T20:07:42Z,2024-04-29T12:38:55Z,,,9db1a51b4d15279fb91d1f8802a1139ee5e76c18,,,0,5b4384fe279abc8eb0b8a4b18c2696e82c59285a,9eb180b7b3df869c21518a17c6fa9eb456551d21,CONTRIBUTOR,,13221727,https://github.com/pydata/xarray/pull/8946,