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/7489#issuecomment-1410899219,https://api.github.com/repos/pydata/xarray/issues/7489,1410899219,IC_kwDOAMm_X85UGJ0T,11656932,2023-01-31T18:51:28Z,2023-01-31T18:51:28Z,CONTRIBUTOR,"Thanks @dcherian. Feel free to let me know if you or others run into this issue elsewhere. I also think it's an edge case the vast majority of users won't encounter (this is the first occurrence I've seen outside of the dask test suite), but if that turns out to not be the case then we can make adjustments upstream in dask 👍 ","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562840229
https://github.com/pydata/xarray/pull/7489#issuecomment-1410880729,https://api.github.com/repos/pydata/xarray/issues/7489,1410880729,IC_kwDOAMm_X85UGFTZ,11656932,2023-01-31T18:34:41Z,2023-01-31T18:34:41Z,CONTRIBUTOR,"Just checking in, @dcherian does this look okay to you? Happy to continue iterating if you see a problem with just removing this config option ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562840229
https://github.com/pydata/xarray/pull/7489#issuecomment-1409284680,https://api.github.com/repos/pydata/xarray/issues/7489,1409284680,IC_kwDOAMm_X85T__pI,11656932,2023-01-30T20:25:22Z,2023-01-30T20:25:22Z,CONTRIBUTOR,"I've not looked super deeply, so please let me know if I'm missing something, but I think that these lines in `get_scheduler` are the relevant ones here 

https://github.com/dask/dask/blob/db5b2178a79cacc1c882d60a82bf86e2e188eccb/dask/base.py#L1405-L1406

Previously, `distributed` would set the `scheduler` config option to point to the default `distributed.Client` (if one existed). We've since changed that logic and `distributed` no no longer uses the config option for saying ""you've got a `distributed.Client`, you should use it"".

I think the problem here is, with the previous config-based behavior, the `scheduler` option, which is currently being set to the single-threaded scheduler in the test suite, would be overwritten by `distributed` to point to the `Client`. However, now that we're no longer using the `scheduler` config option in `distributed`, the test suite is actually using the `single-threaded` scheduler, which is why `get_scheduler()` is returning `get_sync` when using the latest `dask` / `distributed` release. 

I'd argue the new behavior is actually what we want, but I see what you're saying about it being a change in behavior. I think in this case though it's just a tests-related issue. Does that sounds right? Or was setting the `scheduler` config option important for real-life user code too? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562840229
https://github.com/pydata/xarray/pull/7489#issuecomment-1409268444,https://api.github.com/repos/pydata/xarray/issues/7489,1409268444,IC_kwDOAMm_X85T_7rc,11656932,2023-01-30T20:13:16Z,2023-01-30T20:13:16Z,CONTRIBUTOR,"Hmm I'm not able to reproduce with this example using the latest `2023.1.1` release:

```python
In [1]: import dask

In [2]: dask.utils.show_versions()
{
  ""Python"": ""3.10.4"",
  ""Platform"": ""Darwin"",
  ""dask"": ""2023.1.1+3.gdb5b2178a"",
  ""distributed"": ""2023.1.1"",
  ""numpy"": ""1.24.1"",
  ""pandas"": ""2.0.0.dev0+1309.g7f2aa8f46a"",
  ""cloudpickle"": ""2.0.0"",
  ""fsspec"": ""2023.1.0+5.g012816b"",
  ""bokeh"": ""2.4.3"",
  ""fastparquet"": ""2022.12.1.dev6"",
  ""pyarrow"": ""11.0.0.dev316"",
  ""zarr"": ""2.4.1.dev528""
}
In [3]: from distributed import Client

In [4]: type(dask.base.get_scheduler())
Out[4]: NoneType

In [5]: c = Client()

In [6]: dask.base.get_scheduler()
Out[6]: <bound method Client.get of <Client: 'tcp://127.0.0.1:61659' processes=4 threads=8, memory=16.00 GiB>>
```
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562840229
https://github.com/pydata/xarray/pull/7491#issuecomment-1409096508,https://api.github.com/repos/pydata/xarray/issues/7491,1409096508,IC_kwDOAMm_X85T_Rs8,11656932,2023-01-30T18:16:11Z,2023-01-30T18:16:11Z,CONTRIBUTOR,"Ah, indeed -- thanks @jhamman! ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562931560
https://github.com/pydata/xarray/issues/7490#issuecomment-1409095658,https://api.github.com/repos/pydata/xarray/issues/7490,1409095658,IC_kwDOAMm_X85T_Rfq,11656932,2023-01-30T18:15:50Z,2023-01-30T18:15:50Z,CONTRIBUTOR,Closed via https://github.com/pydata/xarray/pull/7458,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1562851680
https://github.com/pydata/xarray/pull/7489#issuecomment-1409005656,https://api.github.com/repos/pydata/xarray/issues/7489,1409005656,IC_kwDOAMm_X85T-7hY,11656932,2023-01-30T17:13:38Z,2023-01-30T17:13:38Z,CONTRIBUTOR,cc @dcherian,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562840229
https://github.com/pydata/xarray/pull/7360#issuecomment-1343080504,https://api.github.com/repos/pydata/xarray/issues/7360,1343080504,IC_kwDOAMm_X85QDcg4,11656932,2022-12-08T17:48:00Z,2022-12-08T17:48:00Z,CONTRIBUTOR,"Looks like the latest `distributed` release is being used in the `mypy` CI build. https://github.com/dask/distributed/pull/7379 will be included in the next release which is currently slated for next Friday, December 16. 

Not sure if it makes sense to temporarily use the `main` branch of `distributed` in CI until then, or use some other `mypy`-related workaround ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1477162465
https://github.com/pydata/xarray/pull/6884#issuecomment-1207088936,https://api.github.com/repos/pydata/xarray/issues/6884,1207088936,IC_kwDOAMm_X85H8rco,11656932,2022-08-05T23:35:56Z,2022-08-05T23:35:56Z,CONTRIBUTOR,It's not immediately clear to me why the docs build is failing. Has that been happening elsewhere? ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1330548427
https://github.com/pydata/xarray/issues/6176#issuecomment-1020681788,https://api.github.com/repos/pydata/xarray/issues/6176,1020681788,IC_kwDOAMm_X8481l48,11656932,2022-01-25T00:19:49Z,2022-01-25T01:27:00Z,CONTRIBUTOR,"> @jrbourbeau is this something dask has thought about?

Thanks for the ping @Illviljan. Zero-padding dates did come up in the Dask calver discussion starting here https://github.com/dask/community/issues/100#issuecomment-704445214. In a nutshell, there was a slight preference towards using zero-padding (i.e. `2022.01.0` instead of `2022.1.0`) because the calendar nature of the version is more explicit and string sorting and full-fledged package sorting (like one would do with `packaging.version`) give the same result. 

As pointed out https://github.com/dask/community/issues/100#issuecomment-704468187 either convention is valid from a Python packaging perspective. FWIW I'm not aware of any issues that have come up from Dask using a zero-padded version number. The main thing that comes to mind is when checking out git tags for a specific release (e.g. `git checkout 2021.04.0` and `git checkout 2021.4.0` are not equivalent). That said, to my knowledge, this hasn't been an issue in practice. 

EDIT: To be clear, I'm not advocating for one convention over the other -- just providing context around Dask's decision","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1108564253
https://github.com/pydata/xarray/issues/5151#issuecomment-920176527,https://api.github.com/repos/pydata/xarray/issues/5151,920176527,IC_kwDOAMm_X8422MeP,11656932,2021-09-15T16:33:45Z,2021-09-15T16:33:45Z,CONTRIBUTOR,https://github.com/dask/dask/pull/8125 was just merged and should resolve this issue ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857301324
https://github.com/pydata/xarray/issues/5654#issuecomment-909333730,https://api.github.com/repos/pydata/xarray/issues/5654,909333730,IC_kwDOAMm_X842M1Ti,11656932,2021-08-31T15:17:44Z,2021-08-31T15:17:44Z,CONTRIBUTOR,"This should be closed via https://github.com/pydata/xarray/pull/5751. Again, thanks all for your efforts! ","{""total_count"": 4, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 2, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-906689573,https://api.github.com/repos/pydata/xarray/issues/5654,906689573,IC_kwDOAMm_X842Cvwl,11656932,2021-08-26T19:38:37Z,2021-08-26T19:38:37Z,CONTRIBUTOR,"Thanks for hunting all this down @crusaderky, I'm currently grokking it. Also cc @hameerabbasi for visibility ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-906631637,https://api.github.com/repos/pydata/xarray/issues/5654,906631637,IC_kwDOAMm_X842ChnV,11656932,2021-08-26T18:12:01Z,2021-08-26T18:12:01Z,CONTRIBUTOR,"Hrm, looking at the [API docs for `sparse.zeros_like`](https://sparse.pydata.org/en/stable/generated/sparse.zeros_like.html), it appears to support `shape=`

```python
In [1]: import sparse

In [2]: sparse.__version__
Out[2]: '0.12.0'

In [3]: import numpy as np

In [4]: x = np.arange(6)

In [5]: y = sparse.zeros_like(x, shape=(3, 2))

In [6]: y
Out[6]: <COO: shape=(3, 2), dtype=int64, nnz=0, fill_value=0>

In [7]: y.todense()
Out[7]:
array([[0, 0],
       [0, 0],
       [0, 0]])
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-905592839,https://api.github.com/repos/pydata/xarray/issues/5654,905592839,IC_kwDOAMm_X841-kAH,11656932,2021-08-25T15:10:10Z,2021-08-25T15:10:10Z,CONTRIBUTOR,Also cc @crusaderky if you get a chance to look into this ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-903022152,https://api.github.com/repos/pydata/xarray/issues/5654,903022152,IC_kwDOAMm_X8410wZI,11656932,2021-08-21T00:30:11Z,2021-08-21T00:30:11Z,CONTRIBUTOR,"Good point. CI is currently pulling in the latest `sparse=0.12.0` release (which is also what I'm running locally). 

It also appears there were some ordering concerns related to https://github.com/dask/dask/issues/5259 when `test_chunk` was added (xref https://github.com/pydata/xarray/pull/3202#discussion_r313098400) ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-903005031,https://api.github.com/repos/pydata/xarray/issues/5654,903005031,IC_kwDOAMm_X8410sNn,11656932,2021-08-20T23:22:35Z,2021-08-20T23:23:28Z,CONTRIBUTOR,"Ah, that's a good point @keewis. Stepping back a bit, my current situation locally is I'm able to reproduce the `xarray/tests/test_sparse.py::test_chunk` failure with:

- the latest commit to `dask` (https://github.com/dask/dask/commit/76822dbc3da29767d7e6d70d73010046bd52604e)
- the latest commit to `xarray` (https://github.com/pydata/xarray/commit/e26aec9500e04f3b926b248988b976dbfcb9c632)
- `numpy=1.21.1`
- `pandas=1.3.1`

Rolling `dask` back to the 2021.7.2 release, but keeping everything else the same, `test_chunk` passes. After running `git bisect` between the latest `dask` commit and the 2021.7.2 release, https://github.com/dask/dask/pull/7939 is the point where `test_chunk` started failing (cc @jakirkham for visibility). I'll try to dig in a bit more to see if I can find the root cause of the failure 

EDIT: I should note that the `test_chunk` failure has a similar traceback to https://github.com/dask/dask/issues/5259","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/issues/5654#issuecomment-899855458,https://api.github.com/repos/pydata/xarray/issues/5654,899855458,IC_kwDOAMm_X841orRi,11656932,2021-08-16T22:20:00Z,2021-08-16T22:35:59Z,CONTRIBUTOR,"Thanks for the ping @dcherian. Running against Dask's `git` history, https://github.com/dask/dask/pull/7939 is the place where `xarray/tests/test_sparse.py::test_chunk` started failing. We probably dropped some relevant compatibility code when we stopped supporting NumPy 1.17 and pandas 0.25. 

Since `xarray` has a [clearly defined policy for minimum dependencies](http://xarray.pydata.org/en/stable/getting-started-guide/installing.html#minimum-dependency-versions), would dropping NumPy 1.17 and pandas 0.25 be an acceptable solution here? ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,957131705
https://github.com/pydata/xarray/pull/5449#issuecomment-856285638,https://api.github.com/repos/pydata/xarray/issues/5449,856285638,MDEyOklzc3VlQ29tbWVudDg1NjI4NTYzOA==,11656932,2021-06-07T21:45:15Z,2021-06-07T21:45:15Z,CONTRIBUTOR,Apologies for the breaking change. I'm happy to make sure we ping an Xarray dev next time we have a significant change to `apply_gufunc` to avoid surprises like this in the future. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,913830070
https://github.com/pydata/xarray/issues/5331#issuecomment-843266284,https://api.github.com/repos/pydata/xarray/issues/5331,843266284,MDEyOklzc3VlQ29tbWVudDg0MzI2NjI4NA==,11656932,2021-05-18T15:22:32Z,2021-05-18T15:22:32Z,CONTRIBUTOR,Thanks for raising an issue @pont-us. I believe this may have been fixed by https://github.com/pydata/xarray/pull/5271 (which was merged just after the 0.18.0 release). Could you install the development version of `xarray` and try again to see if the problem persists? ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,894497993
https://github.com/pydata/xarray/pull/5187#issuecomment-826027314,https://api.github.com/repos/pydata/xarray/issues/5187,826027314,MDEyOklzc3VlQ29tbWVudDgyNjAyNzMxNA==,11656932,2021-04-24T03:34:23Z,2021-04-24T03:34:23Z,CONTRIBUTOR,"Yeah, sorry about that. At least it was an easy fix : ) ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,860711833
https://github.com/pydata/xarray/pull/5187#issuecomment-826025127,https://api.github.com/repos/pydata/xarray/issues/5187,826025127,MDEyOklzc3VlQ29tbWVudDgyNjAyNTEyNw==,11656932,2021-04-24T03:10:54Z,2021-04-24T03:10:54Z,CONTRIBUTOR,@dcherian could you try restarting CI to pull in the latest `dask` release? xref https://github.com/dask/community/issues/150#issuecomment-826025006,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,860711833
https://github.com/pydata/xarray/issues/3303#issuecomment-530939723,https://api.github.com/repos/pydata/xarray/issues/3303,530939723,MDEyOklzc3VlQ29tbWVudDUzMDkzOTcyMw==,11656932,2019-09-12T18:05:12Z,2019-09-12T18:05:12Z,CONTRIBUTOR,This should now be resolved upstream in Dask (xref https://github.com/dask/dask/pull/5399) ,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,492876241