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/7880#issuecomment-1572437423,https://api.github.com/repos/pydata/xarray/issues/7880,1572437423,IC_kwDOAMm_X85duX2v,14808389,2023-06-01T17:01:56Z,2023-06-01T17:06:06Z,MEMBER,"that appears to work on both my laptop and my local HPC, and is arguably a lot easier to implement / understand as we don't need to make sure all the globals we use are still available (which in this case would be `acquire`, `OPTIONS`, `warnings`, and `RuntimeWarning`).
Edit: let me change the PR to do that instead","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1730664352
https://github.com/pydata/xarray/pull/7880#issuecomment-1572384036,https://api.github.com/repos/pydata/xarray/issues/7880,1572384036,IC_kwDOAMm_X85duK0k,14808389,2023-06-01T16:38:23Z,2023-06-01T16:54:08Z,MEMBER,"> Have you verfied that this fixes things at least on your machine?
I thought I did, but apparently something changed: right now it fails because `OPTIONS` is not available anymore, so we might have to add a reference to that, as well. Additionally, for the warning we use `warnings.warn` and `RuntimeWarning` that might also have disappeared already (but those are standard library / builtins, so hopefully not?)
In any case, you can verify this, too:
- create a new environment using `mamba create -n test python=3.11 numpy pandas packaging pooch netcdf4` and activate it
- run `pip install 'dask[array]'` to install `dask` without `distributed` (this appears to make a difference for me, not sure if that's the same elsewhere)
- editable-install `xarray` so we can easily switch between branches
- run `python -c 'import xarray as xr; ds = xr.tutorial.open_dataset(""air_temperature"", chunks={})'`
This should print an error for `main` and shouldn't with this branch (confirmed on my local HPC).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1730664352
https://github.com/pydata/xarray/pull/7880#issuecomment-1572363440,https://api.github.com/repos/pydata/xarray/issues/7880,1572363440,IC_kwDOAMm_X85duFyw,14808389,2023-06-01T16:26:42Z,2023-06-01T16:26:42Z,MEMBER,"the issue is that this doesn't occur on normal garbage collection but only on interpreter shutdown. So really, I don't think we have any way to test this using `pytest` as that itself is written in python (unless of course we can make use of sub-interpreters, but that might be more trouble than it's worth).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1730664352
https://github.com/pydata/xarray/issues/7887#issuecomment-1571698855,https://api.github.com/repos/pydata/xarray/issues/7887,1571698855,IC_kwDOAMm_X85drjin,14808389,2023-06-01T09:39:09Z,2023-06-01T09:39:09Z,MEMBER,"this is #7879 (and thus probably #7079). I suspect our locks are not working properly, but in any case we really should try to fix this.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1735219849
https://github.com/pydata/xarray/issues/7884#issuecomment-1570587416,https://api.github.com/repos/pydata/xarray/issues/7884,1570587416,IC_kwDOAMm_X85dnUMY,14808389,2023-05-31T16:56:16Z,2023-05-31T16:58:23Z,MEMBER,"> No module named '_cffi_backend'
Does simply `import cfgrib` work for you? I suspect it doesn't, which would explain the issue. It's unfortunate that the error is rewritten to ""unknown engine"", but I'm not sure how we would detect that it's a dependency that fails.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1732510720
https://github.com/pydata/xarray/issues/7884#issuecomment-1569021273,https://api.github.com/repos/pydata/xarray/issues/7884,1569021273,IC_kwDOAMm_X85dhV1Z,14808389,2023-05-30T20:07:31Z,2023-05-30T20:08:04Z,MEMBER,"No, this should still work:
```sh
conda create -n test -c conda-forge xarray ipython python=3.11 cfgrib pooch
conda activate test
ipython
```
```python
import xarray as xr
xr.tutorial.open_dataset(""era5-2mt-2019-03-uk.grib"")
```
We somewhat recently dropped the builtin `cfgrib` engine in favor of the one provided by the `cfgrib` package (and that is also the reason why the example in the docs fails: `cfgrib` is not installed into the docs environment anymore, which is definitely an oversight).
Which version of `cfgrib` do you have? For reference, in the environment built with the command above I have `cfgrib=0.9.10.3`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1732510720
https://github.com/pydata/xarray/pull/7876#issuecomment-1568728602,https://api.github.com/repos/pydata/xarray/issues/7876,1568728602,IC_kwDOAMm_X85dgOYa,14808389,2023-05-30T16:25:25Z,2023-05-30T16:25:25Z,MEMBER,"great, thanks for the confirmation!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1729709527
https://github.com/pydata/xarray/issues/7884#issuecomment-1568726002,https://api.github.com/repos/pydata/xarray/issues/7884,1568726002,IC_kwDOAMm_X85dgNvy,14808389,2023-05-30T16:23:30Z,2023-05-30T16:23:30Z,MEMBER,"as stated by the exception, the `cfgrib` engine is unknown, which usually means you're missing the `cfgrib` package (or this is a environment issue). If you did indeed install it, can you post the output of either `conda list` or `pip list` (in case you're not using `conda`)?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1732510720
https://github.com/pydata/xarray/pull/7880#issuecomment-1567446747,https://api.github.com/repos/pydata/xarray/issues/7880,1567446747,IC_kwDOAMm_X85dbVbb,14808389,2023-05-29T19:22:12Z,2023-05-29T19:22:12Z,MEMBER,"> I would have thought that the global (or module level here) variable/function aquire should have at least one reference until after the deletion of the object.
I think this is intended (though certainly not very easy to get right): see the second part of the [warning in the `__del__` documentation](https://docs.python.org/3/reference/datamodel.html#object.__del__).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1730664352
https://github.com/pydata/xarray/issues/7879#issuecomment-1567366415,https://api.github.com/repos/pydata/xarray/issues/7879,1567366415,IC_kwDOAMm_X85dbB0P,14808389,2023-05-29T17:22:09Z,2023-05-29T17:22:09Z,MEMBER,"If I'm reading the different issues correctly, that means this is a duplicate of #7079","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1730451312
https://github.com/pydata/xarray/issues/2697#issuecomment-1567154608,https://api.github.com/repos/pydata/xarray/issues/2697,1567154608,IC_kwDOAMm_X85daOGw,14808389,2023-05-29T13:41:37Z,2023-05-29T13:41:37Z,MEMBER,"closing, since anything still missing should be feature requests for `xncml`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,401874795
https://github.com/pydata/xarray/issues/893#issuecomment-1567147143,https://api.github.com/repos/pydata/xarray/issues/893,1567147143,IC_kwDOAMm_X85daMSH,14808389,2023-05-29T13:33:58Z,2023-05-29T13:34:49Z,MEMBER,I think this has been fixed by `xncml` and/or `kerchunk`.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,163267018
https://github.com/pydata/xarray/issues/7814#issuecomment-1567037851,https://api.github.com/repos/pydata/xarray/issues/7814,1567037851,IC_kwDOAMm_X85dZxmb,14808389,2023-05-29T11:53:37Z,2023-05-29T12:10:00Z,MEMBER,"Actually, it goes away with `pip install jinja2`. We don't use `jinja2` at all, so either this is some kind of weird effect on garbage collection (a timing issue?), or `dask` is doing something differently as soon as `jinja2` is available.
Edit: most likely this is a timing issue... the offending line tries to make use of the internal `acquire` function, which I think at that point has already been destroyed. To fix that, I think we need to somehow store a reference on the file manager?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1695028906
https://github.com/pydata/xarray/issues/7814#issuecomment-1567025628,https://api.github.com/repos/pydata/xarray/issues/7814,1567025628,IC_kwDOAMm_X85dZunc,14808389,2023-05-29T11:41:06Z,2023-05-29T11:56:20Z,MEMBER,"I *can* reproduce this locally:
- download and unpack the files from https://github.com/pydata/xarray/issues/7814#issuecomment-1535168128
- use `mamba create -n test python=3.11 xarray netcdf4` to create the environment (note: no `dask`)
- use `pip install ""dask[array]""` to install `dask` (does not pull `distributed` like the package from `conda-forge`)
- put the code into a script and execute it
For reference, the full traceback is:
```pytb
Exception ignored in:
Traceback (most recent call last):
File ""/home/jmagin/.local/opt/mambaforge/envs/test/lib/python3.9/site-packages/xarray/backends/file_manager.py"", line 246, in __del__
TypeError: 'NoneType' object is not callable
```
As far as I can tell, this means we're using something from `distributed` with a broken fallback, since the error goes away as soon as I *install* `distributed`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1695028906
https://github.com/pydata/xarray/issues/7856#issuecomment-1563092362,https://api.github.com/repos/pydata/xarray/issues/7856,1563092362,IC_kwDOAMm_X85dKuWK,14808389,2023-05-25T15:19:26Z,2023-05-25T15:19:26Z,MEMBER,"how did you set up your environment? This works for me:
```sh
mamba create -n test python=3.11 xarray dask netcdf4 pooch ipython
mamba activate test
ipython
```
```python
xr.tutorial.open_dataset(""rasm"", chunks={})
```
Interestingly enough, though, is that you should only see this with `xarray=2023.5.0`, while your environment claims to have `xarray=2023.4.2`. It seems there is something wrong with your environment?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1718410975
https://github.com/pydata/xarray/issues/7870#issuecomment-1562637946,https://api.github.com/repos/pydata/xarray/issues/7870,1562637946,IC_kwDOAMm_X85dI_Z6,14808389,2023-05-25T10:07:35Z,2023-05-25T10:07:35Z,MEMBER,"I agree, this change should be fine.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1722614979
https://github.com/pydata/xarray/pull/7865#issuecomment-1560060281,https://api.github.com/repos/pydata/xarray/issues/7865,1560060281,IC_kwDOAMm_X85c_KF5,14808389,2023-05-23T20:11:32Z,2023-05-23T20:11:32Z,MEMBER,"this appears to have [worked](https://github.com/pydata/xarray/actions/runs/5061550082). Thanks, @martinfleis!","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 1, ""eyes"": 0}",,1720850091
https://github.com/pydata/xarray/pull/7865#issuecomment-1560049420,https://api.github.com/repos/pydata/xarray/issues/7865,1560049420,IC_kwDOAMm_X85c_HcM,14808389,2023-05-23T20:02:05Z,2023-05-23T20:02:05Z,MEMBER,"> add the token as a `ANACONDA_NIGHTLY` secret.
done. Let's try it!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1720850091
https://github.com/pydata/xarray/pull/7865#issuecomment-1559677947,https://api.github.com/repos/pydata/xarray/issues/7865,1559677947,IC_kwDOAMm_X85c9sv7,14808389,2023-05-23T15:33:46Z,2023-05-23T15:33:46Z,MEMBER,"> Do we need to build the wheel in the same way you currently do in [the TestPyPI workflow]
depends on whether we can put local versions on anaconda. PyPI and TestPyPI don't allow that, so we had to modify `pyproject.toml` to make `setuptools-scm` generate versions without the local part.
> Do you have an account there so I can add you?
now I do, the username is the same as on github.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1720850091
https://github.com/pydata/xarray/pull/7867#issuecomment-1559210203,https://api.github.com/repos/pydata/xarray/issues/7867,1559210203,IC_kwDOAMm_X85c76jb,14808389,2023-05-23T12:33:48Z,2023-05-23T12:33:48Z,MEMBER,"since the version *with* `cdms2` fails on environment creation we can't really remove the special case for `python=3.11` until we reached a decision on what to do with `cdms2` support. I'll open a new issue for that, but otherwise this should be ready for merging.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1721896187
https://github.com/pydata/xarray/issues/7863#issuecomment-1557705518,https://api.github.com/repos/pydata/xarray/issues/7863,1557705518,IC_kwDOAMm_X85c2LMu,14808389,2023-05-22T18:33:15Z,2023-05-22T18:33:15Z,MEMBER,"I wonder if pure-python projects could get away with asking to install from github? This works today:
```sh
pip install git+https://github.com/pydata/xarray.git
```
and we have been using it downstream in nightly CI.
That said, I can see a central location being helpful, and we'd certainly be happy to add a scheduled github action to upload built packages. We'd need some help with setting that up, though, as I personally don't have any experience whatsoever in uploading to `anaconda.org`. Do you have documentation/examples on how to do the actual upload?
That would also allow us to stop publishing builds to TestPyPI (not sure if those are nightlies), as that seems to have accumulated quite a few packages already that due to the PyPI policy stay there forever.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1720191529
https://github.com/pydata/xarray/issues/7707#issuecomment-1555902158,https://api.github.com/repos/pydata/xarray/issues/7707,1555902158,IC_kwDOAMm_X85cvS7O,14808389,2023-05-20T12:32:47Z,2023-05-20T15:26:43Z,MEMBER,"with #7855 and the recent change to `pint` we're finally down to just two test failures (and a whole lot of warnings):
```
xarray/tests/test_dataarray.py::TestDataArray::test_to_and_from_cdms2_sgrid: ValueError: operands could not be broadcast together with shapes (3,) (4,)
xarray/tests/test_ufuncs.py::test_unary: AssertionError: assert ( is or 1.0 == 0.9999999999999999)
```
The first one looks like `cdms2` is incompatible with a change in `numpy>=1.25`. Not sure if we can do anything about that, especially since there's a big warning on the [cdms2 repo](https://github.com/CDAT/cdms) stating that the package is going to be retired / archived by the end of this year... I guess we should start thinking about removing `cdms2` support?
The second looks like a precision issue, which we should be able to resolve by using `assert_allclose` instead... not sure, though, especially given numpy/numpy#23773. Otherwise we could just defer to whatever `numpy` is doing (of course, that assumes that `full_like` works properly, which might not be a good idea for a unit test):
```python
@pytest.mark.parametrize(
""a"",
[
xr.Variable([""x""], [0, 0]),
xr.DataArray([0, 0], dims=""x""),
xr.Dataset({""y"": (""x"", [0, 0])}),
],
)
def test_unary(a):
fill_value = np.cos(0)
expected = xr.full_like(a, fill_value=fill_value, dtype=fill_value.dtype)
actual = np.cos(a)
assert_identical(actual, expected)
```
Edit: if relying on `full_like` turns out to be a concern, maybe we could use ""copy + assign"" instead?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1650481625
https://github.com/pydata/xarray/pull/7840#issuecomment-1546028265,https://api.github.com/repos/pydata/xarray/issues/7840,1546028265,IC_kwDOAMm_X85cJoTp,14808389,2023-05-12T16:56:23Z,2023-05-12T16:56:23Z,MEMBER,"let's have a look at what defines the object:
```python
data = xr.DataArray(np.random.randn(2, 3), dims=(""x"", ""y""), coords={""x"": [10, 20]})
```
That means we have:
- random data
- two dimensions: x with a length of 2 and y with a length of 3
- one coordinate: x with values `[10, 20]`
The line
```python
data.x.attrs[""units""] = ""x units""
```
can be split into two parts:
```python
x = data.x
```
and
```python
x.attrs[""units""] = ""x units""
```
where `x` is the coordinate.
If we did the same thing with `y` we would *not* get the dimension, but a dummy coordinate that has the values `np.arange(data.sizes[""y""])`. This is admittedly a bit confusing.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1707774178
https://github.com/pydata/xarray/pull/7840#issuecomment-1545937746,https://api.github.com/repos/pydata/xarray/issues/7840,1545937746,IC_kwDOAMm_X85cJSNS,14808389,2023-05-12T15:37:59Z,2023-05-12T15:37:59Z,MEMBER,"I agree, coordinate is the correct term. We could make that a bit less confusing by using a non-dimension coordinate in the example, but then again the point is that any coordinate can have additional metadata.
> But I think the concept of dimension-coordinates (when the coordinate has the same name as the dimension) is still relevant.
If I remember correctly, while they lost their status as the only ones having an index dimension coordinates are still used for alignment.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1707774178
https://github.com/pydata/xarray/issues/7707#issuecomment-1536641744,https://api.github.com/repos/pydata/xarray/issues/7707,1536641744,IC_kwDOAMm_X85bl0rQ,14808389,2023-05-05T18:48:42Z,2023-05-05T18:48:42Z,MEMBER,"`pint<0.21` should work, and I'm looking into how this could be fixed, see hgrecco/pint#1660 and hgrecco/pint#1749. For the latter we might have to mark the ""pint wrapping dask"" test as requiring `pint>=0.21` and make it use an explicit registry.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1650481625
https://github.com/pydata/xarray/issues/7765#issuecomment-1531336259,https://api.github.com/repos/pydata/xarray/issues/7765,1531336259,IC_kwDOAMm_X85bRlZD,14808389,2023-05-02T11:52:35Z,2023-05-02T11:52:35Z,MEMBER,reopening so I can keep track of the second task: creating and automatically updating the support table,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421
https://github.com/pydata/xarray/pull/7793#issuecomment-1529028318,https://api.github.com/repos/pydata/xarray/issues/7793,1529028318,IC_kwDOAMm_X85bIx7e,14808389,2023-04-30T13:39:34Z,2023-04-30T13:39:56Z,MEMBER,"the first part of the policy change discussed in #7765 should be ready for review and merging. Still pondering how to implement the second part, so that will be a separate PR.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1688716198
https://github.com/pydata/xarray/issues/7764#issuecomment-1525068958,https://api.github.com/repos/pydata/xarray/issues/7764,1525068958,IC_kwDOAMm_X85a5rSe,14808389,2023-04-27T08:11:25Z,2023-04-27T08:11:25Z,MEMBER,"we still want to be able to explicitly switch it off as we did for bottleneck (mostly for debugging purposes), so the kwarg / option would be good to have either way. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1672288892
https://github.com/pydata/xarray/issues/7765#issuecomment-1523691256,https://api.github.com/repos/pydata/xarray/issues/7765,1523691256,IC_kwDOAMm_X85a0a74,14808389,2023-04-26T16:14:25Z,2023-04-26T16:20:14Z,MEMBER,"In the meeting today we decided to both change the min-versions policy for python to 30 months, and to add a release table (something like the one in NEP29, but automatically created with each newly released version – possibly through a polling action that runs once a week or something so we don't increase the docs build time any more). The reason for the latter is that the policy, while a good policy, is not easy to understand, and its full meaning can only be inferred by reading the `min_versions_policy` script.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421
https://github.com/pydata/xarray/issues/7777#issuecomment-1517915386,https://api.github.com/repos/pydata/xarray/issues/7777,1517915386,IC_kwDOAMm_X85aeYz6,14808389,2023-04-21T14:25:13Z,2023-04-21T20:05:38Z,MEMBER,"see also #7765, where there is a bit more information and discussion.
In short, the policy did work *like* NEP-29 before, but stopped doing so with python 3.8 because python switched from a irregular ~18 month release cycle to a regular 12 month cycle. We can adjust our policy by extending these 24 months to 30 months, which makes it align with NEP-29's 42 months window.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1678587031
https://github.com/pydata/xarray/issues/7772#issuecomment-1517659721,https://api.github.com/repos/pydata/xarray/issues/7772,1517659721,IC_kwDOAMm_X85adaZJ,14808389,2023-04-21T11:05:40Z,2023-04-21T11:05:40Z,MEMBER,"that's a numpy array with sparse data. What @TomNicholas was talking about is a array of type `sparse.COO` (from the [sparse](https://github.com/pydata/sparse/) package).
And as far as I can tell, our wrapper class (which is the reason why you don't get the memory error on open) does not define `nbytes`, so at the moment there's no way to do that. You could try using `dask`, though, which does allow working with bigger-than-memory data.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1676561243
https://github.com/pydata/xarray/issues/7721#issuecomment-1516251985,https://api.github.com/repos/pydata/xarray/issues/7721,1516251985,IC_kwDOAMm_X85aYCtR,14808389,2023-04-20T12:35:30Z,2023-04-20T12:36:55Z,MEMBER,"there's two things that happen in `as_shared_dtype` (which may not be good design, and we should probably consider splitting it into `as_shared_dtype` and `as_compatible_arrays` or something): first, we cast everything to an array, then decide on a common dtype and cast everything to that.
The latter could easily be done by using `numpy` scalars, which as far as I can tell would be supported by most array libraries, including `cupy`. However, the reason we *need* to cast to arrays is that the array API (i.e. `__array_namespace__`) does not allow using scalars of any type, e.g. `np.array_api.where` (this is important for libraries that don't implement `__array_ufunc__` / `__array_function__`). To clarify, what we're trying to support is something like
```python
import numpy.array_api as np
np.where(cond, cupy_array, python_scalar)
```
which (intentionally?) does not work.
At the moment, `as_shared_dtype` (or, really, the hypothetical `as_compatible_arrays`) correctly casts `python_scalar` to a 0-d `cupy.array` for the example above, but if we were to replace `cupy_array` with `chunked_cupy_array` or `chunked_cupy_array_with_units`, the special casing for `cupy` stops to work and scalars will be cast to 0-d `numpy.array`. Conceptually, I tend to think of 0-d arrays as equivalent to scalars, hence the suggestion to have `cupy` treat `numpy` scalars and 0-d `numpy.array` the same way (I don't follow the array api closely enough to know whether that was already discussed and rejected).
So really, my question is: how do we support python scalars for libraries that only implement `__array_namespace__`, given that stopping to do so would be a major breaking change?
Of course, I would prefer removing the special casing for specific libraries, but I wouldn't be opposed to keeping the existing one. I guess as a short-term fix we could just pull `_meta` out of duck dask arrays and determine the common array type for that (the downside is that we'd add another special case for `dask`, which in another PR we're actually trying to remove).
As a long-term fix I guess we'd need to revive the stalled nested duck array discussion.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655290694
https://github.com/pydata/xarray/issues/7767#issuecomment-1514489469,https://api.github.com/repos/pydata/xarray/issues/7767,1514489469,IC_kwDOAMm_X85aRUZ9,14808389,2023-04-19T10:20:08Z,2023-04-19T10:20:08Z,MEMBER,"According to #503, there's two reasons: the fact that for masking this is so much easier to write (including when method chaining), and it is also API inherited from `pandas`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1674532233
https://github.com/pydata/xarray/issues/7767#issuecomment-1514441250,https://api.github.com/repos/pydata/xarray/issues/7767,1514441250,IC_kwDOAMm_X85aRIoi,14808389,2023-04-19T09:45:27Z,2023-04-19T09:46:47Z,MEMBER,"to elaborate on that, `xr.DataArray.where` uses `self` as ""then"" and the second argument as ""other"", while for `xr.where` the second argument is ""then"" and the third argument is ""other"" (the condition is the first argument for both).
This API allows masking using just
```python
arr.where(mask)
```","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1674532233
https://github.com/pydata/xarray/issues/7765#issuecomment-1513673945,https://api.github.com/repos/pydata/xarray/issues/7765,1513673945,IC_kwDOAMm_X85aONTZ,14808389,2023-04-18T19:15:21Z,2023-04-18T19:16:36Z,MEMBER,"> Is the policy working as designed
yes, it is: we guarantee support for at least 24 months, and only drop support once there's another version of python that was released more than 24 months ago. For example, python 3.8 was initially released on Oct 14, 2019 and python 3.9 was released on Oct 5, 2020. According to our policy we were able to drop python 3.8 for releases after Oct 5, 2022, since that's when python 3.9 was released 24 months ago.
This works very well for infrequent releases, since it guarantees that we don't accidentally require a very new version immediately after its release. However, these admittedly a bit complicated rules make interpreting the policy a bit more challenging than a simple ""X months from this release"" would for projects with frequent releases. Maybe we should add a (automatically created) support table for the core dependencies to the installation guide to make reasoning about the policy easier?
> Python: 24 months from the last bugfix release (security releases are not considered).
That would make the support window less predictable, since the python devs might consider an additional bugfix release depending on the situation (there's a reason why the release peps say, *emphasis mine*: ""X will receive bugfix updates *approximately* every 2 months for *approximately* 18 months""). Instead, maybe we should extend the support for python versions by about 6 months, to a total of 30 months? That would effectively align us with NEP-29, which is our upper limit anyways since that's what our dependencies follow (even if their releases don't usually happen at exactly that date).
And before anyone claims we're dropping support for a python version just because our policy tells us to: I'm excited about a number of changes to python, like the `dict` union and `removeprefix` / `removesuffix` in 3.9, the union types in 3.10, and the exception groups in 3.11, so really there *is* a compelling reason to upgrade as soon as the policy allows for each release.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421
https://github.com/pydata/xarray/issues/7707#issuecomment-1510443977,https://api.github.com/repos/pydata/xarray/issues/7707,1510443977,IC_kwDOAMm_X85aB4vJ,14808389,2023-04-16T17:55:12Z,2023-04-16T17:57:23Z,MEMBER,"flaky segfaults aside, we're down to just the zarr v3 tests, a flaky `cdms2` test, and a test related to `pint` (though that one appears to be an upstream issue – not entirely sure, though).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1650481625
https://github.com/pydata/xarray/issues/7716#issuecomment-1510442337,https://api.github.com/repos/pydata/xarray/issues/7716,1510442337,IC_kwDOAMm_X85aB4Vh,14808389,2023-04-16T17:47:07Z,2023-04-16T17:51:39Z,MEMBER,"I'm on a train wifi, so not really better. However, I think this is because `xarray=2023.04.0` is not on `conda-forge`, yet (the PR to the feedstock still has to be merged), so you can't install `xarray` and `pandas=2` into the same environment. As a workaround, you can try installing `xarray` using `pip`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522
https://github.com/pydata/xarray/issues/7716#issuecomment-1510434058,https://api.github.com/repos/pydata/xarray/issues/7716,1510434058,IC_kwDOAMm_X85aB2UK,14808389,2023-04-16T17:08:16Z,2023-04-16T17:08:16Z,MEMBER,"can you share a bit more about the environment you're trying to create? Is that by chance a `py38` environment, or does one of the libraries you're trying to install have a upper bound for `xarray`? `xarray>=2023.04.0` does not have the pin on `pandas` anymore, so you should be able to install that even if the repodata patches didn't work.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522
https://github.com/pydata/xarray/issues/7721#issuecomment-1510169910,https://api.github.com/repos/pydata/xarray/issues/7721,1510169910,IC_kwDOAMm_X85aA102,14808389,2023-04-16T08:09:09Z,2023-04-16T08:09:09Z,MEMBER,"The issue is that here: https://github.com/pydata/xarray/blob/d4db16699f30ad1dc3e6861601247abf4ac96567/xarray/core/duck_array_ops.py#L193-L206 we try to convert everything to the same dtype, casting numpy and python scalars to an array. The latter is important, because e.g. `numpy.array_api.where` only accepts arrays as input.
However, detecting `cupy` beneath (multiple) layers of duckarrays is not easy, which means that for example passing a `pint(dask(cupy))` array together with scalars will currently cast the scalars to 0-d `numpy` arrays, while passing a `cupy` array instead will result in 0-d `cupy` arrays.
My naive suggestion was to treat `np.int64(0)` and `np.array(0, dtype=""int64"")` the same, where at the moment the latter would fail for the same reason as `np.array([0], dtype=""int64"")`.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655290694
https://github.com/pydata/xarray/pull/7724#issuecomment-1504083577,https://api.github.com/repos/pydata/xarray/issues/7724,1504083577,IC_kwDOAMm_X85Zpn55,14808389,2023-04-11T21:00:05Z,2023-04-11T21:00:05Z,MEMBER,"no, `mypy` should be fine, as the CI version does not complain and I assume whatever the hook is reporting is also present on `main` (I didn't check, though).
As far as I can tell, the only thing left is another round of reviews.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655782486
https://github.com/pydata/xarray/pull/7724#issuecomment-1501135058,https://api.github.com/repos/pydata/xarray/issues/7724,1501135058,IC_kwDOAMm_X85ZeYDS,14808389,2023-04-09T13:57:19Z,2023-04-09T13:57:19Z,MEMBER,"> I think we could check if the newest mypy still segfaults or not...
it didn't for me when I ran the hook, but that might just have been luck. To confirm, we'd need a PR that unpins `mypy` and potentially fixes all the errors that popped up since.
The `mypy` hook didn't take that long, but I guess it's the accumulated time that counts. Also, I learned today that the `black-jupyter` hook does all that `black` does *plus* format notebooks, so removing `id: black` should also shave off a bit.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655782486
https://github.com/pydata/xarray/pull/7724#issuecomment-1500113295,https://api.github.com/repos/pydata/xarray/issues/7724,1500113295,IC_kwDOAMm_X85ZaemP,14808389,2023-04-07T09:25:49Z,2023-04-07T09:25:49Z,MEMBER,"@Illviljan, @headtr1ck, I just noticed that the CI version of `mypy` is pinned to `<0.990`, but the `pre-commit` hook is at `1.1.1`. Is that intentional / known? Running the hook also exposes quite a few typing errors.
Otherwise this should be ready for a final review, and the failing datetime-related tests will be fixed by #7731.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655782486
https://github.com/pydata/xarray/pull/7731#issuecomment-1499092482,https://api.github.com/repos/pydata/xarray/issues/7731,1499092482,IC_kwDOAMm_X85ZWlYC,14808389,2023-04-06T13:48:06Z,2023-04-06T13:48:06Z,MEMBER,"sorry, I forgot about being able to use the upstream-dev environment for testing. That should solve just fine since by design it ignores all pinned dependencies, but we currently get occasional segfaults and unrelated failing tests, and we only test on a single OS / python version.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1657396474
https://github.com/pydata/xarray/pull/7731#issuecomment-1499063414,https://api.github.com/repos/pydata/xarray/issues/7731,1499063414,IC_kwDOAMm_X85ZWeR2,14808389,2023-04-06T13:26:22Z,2023-04-06T13:26:22Z,MEMBER,"to properly test this, I guess we'd need to merge #7724 first?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1657396474
https://github.com/pydata/xarray/pull/7724#issuecomment-1498929670,https://api.github.com/repos/pydata/xarray/issues/7724,1498929670,IC_kwDOAMm_X85ZV9oG,14808389,2023-04-06T11:40:12Z,2023-04-06T11:40:12Z,MEMBER,"It seems this fixes the failing tests unrelated to the `datetime64` range.
Regarding the failing doctests, I decided to cast the values of `arr.dt.` to `int64` to keep the API unchanged. However, if we decide to follow `pandas` and return `int32` I'm happy to make that change.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1655782486
https://github.com/pydata/xarray/issues/3921#issuecomment-1498756227,https://api.github.com/repos/pydata/xarray/issues/3921,1498756227,IC_kwDOAMm_X85ZVTSD,14808389,2023-04-06T09:25:44Z,2023-04-06T09:25:58Z,MEMBER,"I think we'd need to be able to remove this `xfail` first: https://github.com/pydata/xarray/blob/f8127fc9ad24fe8b41cce9f891ab2c98eb2c679a/xarray/tests/test_backends.py#L712-L714 I didn't check, this could be `xpass`ing right now.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,590630281
https://github.com/pydata/xarray/issues/7716#issuecomment-1497664639,https://api.github.com/repos/pydata/xarray/issues/7716,1497664639,IC_kwDOAMm_X85ZRIx_,14808389,2023-04-05T15:16:12Z,2023-04-06T08:38:30Z,MEMBER,"CI says these are the tests we'd need to fix:
```
FAILED xarray/tests/test_coding_times.py::test_should_cftime_be_used_source_outside_range - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[360_day] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[365_day] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[366_day] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[all_leap] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[gregorian] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[julian] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[noleap] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[proleptic_gregorian] - Failed: DID NOT RAISE
FAILED xarray/tests/test_cftimeindex.py::test_to_datetimeindex_out_of_range[standard] - Failed: DID NOT RAISE
FAILED xarray/tests/test_dataarray.py::TestDataArray::test_sel_float - NotImplementedError: float16 indexes are not supported
```
Edit: one more on windows:
```
FAILED xarray/tests/test_utils.py::test_maybe_coerce_to_str[1-2-expected1] - AssertionError: assert dtype('int64') == dtype('int32')
+ where dtype('int64') = Index([1, 2], dtype='int64').dtype
+ and dtype('int32') = Index([1, 2], dtype='int32').dtype
```
Edit2: the doctests also fail:
```
FAILED xarray/core/accessor_dt.py::xarray.core.accessor_dt.DatetimeAccessor
FAILED xarray/core/accessor_dt.py::xarray.core.accessor_dt.TimedeltaAccessor
FAILED xarray/core/dataarray.py::xarray.core.dataarray.DataArray.groupby
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522
https://github.com/pydata/xarray/issues/7716#issuecomment-1498186880,https://api.github.com/repos/pydata/xarray/issues/7716,1498186880,IC_kwDOAMm_X85ZTISA,14808389,2023-04-05T21:30:41Z,2023-04-05T21:35:25Z,MEMBER,"For `test_should_cftime_be_used_source_outside_range` and `test_to_datetimeindex_out_of_range` I'd probably use a date that is outside the `s` resolution range (not sure if that actually makes sense, though). What do you think, @spencerkclark?
For `test_maybe_coerce_to_str` I think the reason is that we use `np.array` to cast a python `int` to an array, but the default resolution is different on windows. Apparently, `pandas` still uses `int64` if constructed directly from python `int`s, but `numpy` uses `int32` on windows, and as you say `pandas` does not insist on `int64` anymore. The fix would be to explicitly specify the `dtype` in the `array` calls.
And finally, I'm not sure what to do with `test_sel_float`. Maybe we can split the monolithic test into one parametrized by `dtype` and skip the `float16` test variant for `pandas>=2.0`?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522
https://github.com/pydata/xarray/issues/7716#issuecomment-1497623839,https://api.github.com/repos/pydata/xarray/issues/7716,1497623839,IC_kwDOAMm_X85ZQ-0f,14808389,2023-04-05T14:51:16Z,2023-04-05T14:51:16Z,MEMBER,"with the merge of #7441 we should already support `pandas=2.0` on `main`. I think we can try unpinning in a PR to see how many of the errors from #7707 are related to `pandas` (none, hopefully, but I'm not sure).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522
https://github.com/pydata/xarray/issues/7707#issuecomment-1496211311,https://api.github.com/repos/pydata/xarray/issues/7707,1496211311,IC_kwDOAMm_X85ZLl9v,14808389,2023-04-04T15:47:28Z,2023-04-04T15:47:28Z,MEMBER,"it seems the tests segfaulted again. Not sure which test exactly is causing that, though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1650481625
https://github.com/pydata/xarray/issues/7420#issuecomment-1492967425,https://api.github.com/repos/pydata/xarray/issues/7420,1492967425,IC_kwDOAMm_X85Y_OAB,14808389,2023-04-01T13:11:31Z,2023-04-01T13:11:31Z,MEMBER,"let's close this and have the CI open a new issue for the other failing tests. I will point out, though, that the [most recent run](https://github.com/pydata/xarray/actions/runs/4580161924/jobs/8088617233) appears to have segfaulted.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1519784328
https://github.com/pydata/xarray/pull/7441#issuecomment-1492947179,https://api.github.com/repos/pydata/xarray/issues/7441,1492947179,IC_kwDOAMm_X85Y_JDr,14808389,2023-04-01T11:47:07Z,2023-04-01T11:47:07Z,MEMBER,"the commit with my fix seems to have passed all CI (although using `isoformat(sep="" "")` is much better), and the upstream-dev CI only failed with unrelated issues, so once CI passes I think we can finally merge this.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729
https://github.com/pydata/xarray/issues/7703#issuecomment-1491930259,https://api.github.com/repos/pydata/xarray/issues/7703,1491930259,IC_kwDOAMm_X85Y7QyT,14808389,2023-03-31T13:30:54Z,2023-03-31T13:30:54Z,MEMBER,"the new version is on `conda-forge`, rerunning the failed CI should work now.","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1648748263
https://github.com/pydata/xarray/issues/7703#issuecomment-1491612766,https://api.github.com/repos/pydata/xarray/issues/7703,1491612766,IC_kwDOAMm_X85Y6DRe,14808389,2023-03-31T09:19:24Z,2023-03-31T09:19:38Z,MEMBER,"there's a bugfix release of `sphinx-book-theme` that has been released about two hours ago, we're just waiting on that to propagate to `conda-forge`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1648748263
https://github.com/pydata/xarray/issues/7692#issuecomment-1487609291,https://api.github.com/repos/pydata/xarray/issues/7692,1487609291,IC_kwDOAMm_X85Yqx3L,14808389,2023-03-28T21:21:47Z,2023-03-28T21:21:47Z,MEMBER,"As far as I understand #5954 and the meeting notes, we didn't decide anything about that yet (I might be wrong, though). So I assume the only reason we don't have write backends and `save_dataset` / `save_dataarray` right now is that nobody got around to doing that yet.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1644429340
https://github.com/pydata/xarray/issues/7692#issuecomment-1487433218,https://api.github.com/repos/pydata/xarray/issues/7692,1487433218,IC_kwDOAMm_X85YqG4C,14808389,2023-03-28T18:44:39Z,2023-03-28T18:44:39Z,MEMBER,"I guess the alternative would be to go with `xr.save_dataset` / `xr.save_dataarray`, but that seems like a lot of work (*and* I agree that since we already have `Dataset.to_zarr` we can also have `DataArray.to_zarr`)
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1644429340
https://github.com/pydata/xarray/issues/7686#issuecomment-1485752281,https://api.github.com/repos/pydata/xarray/issues/7686,1485752281,IC_kwDOAMm_X85YjsfZ,14808389,2023-03-27T19:33:59Z,2023-03-27T19:36:46Z,MEMBER,see also #6323 and #4817,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1642635191
https://github.com/pydata/xarray/issues/4361#issuecomment-1483122791,https://api.github.com/repos/pydata/xarray/issues/4361,1483122791,IC_kwDOAMm_X85YZqhn,14808389,2023-03-24T16:58:09Z,2023-03-24T20:24:31Z,MEMBER,"that looks like a good start, thanks.
I wonder if we should change the structure to start with an overview, then link to in-depth guides (just throwing out ideas):
1. project structure
- code
- docs
- packaging (?)
- automation
2. high-level description of a typical workflow (just list the steps and link to relevant documentation):
- setup environment
- create branch
- edit files
- run tests / build docs / run doctests (plus point to CI: for small changes no need to build manually)
- commit
- push to fork
- create PR
- what to do for very short changes (e.g. typo fixes)
3. set up environments (purpose: code including doctests, docs)
- install dependencies (including special things to do for each OS)
- install xarray
4. code standards and conventions
5. tests
6. typing
7. docstring conventions
- format: numpydoc
- examples (doctests)
- see also
9. how to run tests
10. how to build docs
11. how to run doctests
12. special stuff when committing
- `pre-commit` (and the `pre-commit-ci` bot)
- commit message tags for controlling CI
13. PR title and message (short section on what to put into the PR description / title)
If that would be easier to follow, we could also split 2) into multiple parts: workflow for code changes (including doctest), workflow for documentation changes. And since we most likely will never be the best source for documentation on general git / github, try to link to other sources like https://docs.github.com or https://git-scm.com
Edit: I guess we could also combine 5 and 9, and 7, 10 and 11","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,683142059
https://github.com/pydata/xarray/pull/7657#issuecomment-1483092471,https://api.github.com/repos/pydata/xarray/issues/7657,1483092471,IC_kwDOAMm_X85YZjH3,14808389,2023-03-24T16:35:17Z,2023-03-24T16:37:45Z,MEMBER,"depends on the test, I guess. Most of them are related to one of the netcdf backends (not sure which, the tests don't specify that), `test_dataarray_compute` just checks `_in_memory` (no I/O involved), and the pydap tests use netcdf underneath. So I'd say the issue is with one of the netcdf backends (`netcdf4`, as that's first in the priority list).
I've also seen a drastic reduction in performance with HDF5 1.12.2 (both netcdf4 and h5netcdf) on one of my colleague's datasets, so maybe that's much more visible on a mac? That doesn't explain the slow `test_dataarray_compute`, though.
Do we isolate the dask scheduler in any way? I assume that makes use of the builtin (non-`distributed`) scheduler?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1635470616
https://github.com/pydata/xarray/pull/7657#issuecomment-1483049816,https://api.github.com/repos/pydata/xarray/issues/7657,1483049816,IC_kwDOAMm_X85YZYtY,14808389,2023-03-24T16:04:28Z,2023-03-24T16:04:28Z,MEMBER,"> Is it for a particular backend?
Not sure I understand. Can you elaborate, please?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1635470616
https://github.com/pydata/xarray/pull/7657#issuecomment-1481344641,https://api.github.com/repos/pydata/xarray/issues/7657,1481344641,IC_kwDOAMm_X85YS4aB,14808389,2023-03-23T14:56:17Z,2023-03-23T14:56:17Z,MEMBER,"since the `macos` 3.11 CI is not required, I'm tempted to merge this now, and continue to debug elsewhere.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1635470616
https://github.com/pydata/xarray/pull/7664#issuecomment-1481327369,https://api.github.com/repos/pydata/xarray/issues/7664,1481327369,IC_kwDOAMm_X85YS0MJ,14808389,2023-03-23T14:46:02Z,2023-03-23T14:54:42Z,MEMBER,"should we use a released version of `actions/labeler`? A change to their `main` branch seems to have broken our workflow, but that's something to be expected, I guess.
Edit: turns out we had a workaround in our workflow, which has been fixed upstream (but broke the workaround). I think we have two options: keep the workaround but use `v4`, or stay on `main` and remove the workaround. The latter seems better in the long term, but staying on `main` involves the risk of unexpected changes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1637616804
https://github.com/pydata/xarray/pull/7657#issuecomment-1480905116,https://api.github.com/repos/pydata/xarray/issues/7657,1480905116,IC_kwDOAMm_X85YRNGc,14808389,2023-03-23T10:00:54Z,2023-03-23T10:05:37Z,MEMBER,"I guess that means that the CPUs of the windows and macos runners are just slow, or there's other tasks that get prioritized, or something. All of this results in the tests being pretty flaky, so I'm not sure what we can do about it. I don't have access to any, but maybe someone with a mac could try to reproduce?
In any case, I'll increase the timeout a bit again since I think a timeout after ~1hour is better than the CI job being cancelled after 6 hours.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1635470616
https://github.com/pydata/xarray/issues/7634#issuecomment-1479839303,https://api.github.com/repos/pydata/xarray/issues/7634,1479839303,IC_kwDOAMm_X85YNI5H,14808389,2023-03-22T15:57:52Z,2023-03-22T15:57:52Z,MEMBER,"we don't usually assign issues, so you're free to just submit a pull request (don't forget to add tests that verify the new encoding actually works, though)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1626630088
https://github.com/pydata/xarray/pull/7657#issuecomment-1479671510,https://api.github.com/repos/pydata/xarray/issues/7657,1479671510,IC_kwDOAMm_X85YMf7W,14808389,2023-03-22T14:29:20Z,2023-03-22T14:29:20Z,MEMBER,"apparently python 3.11 on windows is also pretty slow, which makes the timeouts appear there as well. But in any case, here's the affected tests:
```
FAILED xarray/tests/test_backends.py::TestDask::test_dask_roundtrip - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestDask::test_deterministic_names - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestDask::test_dataarray_compute - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestDask::test_load_dataset - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestDask::test_load_dataarray - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestDask::test_inline_array - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestPydap::test_cmp_local_file - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestPydap::test_compatible_to_netcdf - Failed: Timeout >90.0s
FAILED xarray/tests/test_backends.py::TestPydap::test_dask - Failed: Timeout >90.0s
```
which are the exact same tests that also fail for >300s, so I'm guessing those are the ones that stall.
Does anyone know why those take so long only on macos (and, partially, windows)? Does that have to do with the runner hardware?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1635470616
https://github.com/pydata/xarray/issues/7630#issuecomment-1469714769,https://api.github.com/repos/pydata/xarray/issues/7630,1469714769,IC_kwDOAMm_X85XmhFR,14808389,2023-03-15T10:07:06Z,2023-03-15T10:07:06Z,MEMBER,"you can also pass a `dict`, so `nc.loc[{""time"": dt}]` or `nc.loc[dict(time=dt)]` should work as well","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1624560934
https://github.com/pydata/xarray/pull/7619#issuecomment-1466134208,https://api.github.com/repos/pydata/xarray/issues/7619,1466134208,IC_kwDOAMm_X85XY27A,14808389,2023-03-13T13:20:15Z,2023-03-13T13:20:15Z,MEMBER,"this looks good to me, but we'd need some tests to make sure we don't reintroduce this issue. I'd probably extend the `""simple""` case of `xarray/tests/test_computation.py::test_polyval` by creating two versions: one with `int32` values for `degree` and one with `int64` values","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1621385466
https://github.com/pydata/xarray/pull/7619#issuecomment-1466127429,https://api.github.com/repos/pydata/xarray/issues/7619,1466127429,IC_kwDOAMm_X85XY1RF,14808389,2023-03-13T13:15:40Z,2023-03-13T13:15:40Z,MEMBER,"this happens with any code that calls `polyval` on coefficients with `int32` dtypes. The example from the docs:
```python
In [19]: import xarray as xr
...:
...: x = xr.DataArray(np.arange(10), dims=[""x""], name=""x"")
...: a = xr.DataArray(3 + 4 * x, dims=[""x""], coords={""x"": x})
...: out = a.polyfit(dim=""x"", deg=1, full=True)
...: out
Out[19]:
Dimensions: (degree: 2)
Coordinates:
* degree (degree) int64 1 0
Data variables:
x_matrix_rank int64 2
x_singular_values (degree) float64 1.358 0.3963
polyfit_coefficients (degree) float64 4.0 3.0
polyfit_residuals float64 4.522e-28
In [20]: xr.polyval(coord=x, coeffs=out.assign_coords(degree=out.degree.astype(""int64"")))
Out[20]:
Dimensions: (x: 10)
Dimensions without coordinates: x
Data variables:
x_matrix_rank (x) int64 2 4 6 8 10 12 14 16 18 20
x_singular_values (x) float64 0.3963 1.754 3.111 ... 9.899 11.26 12.61
polyfit_coefficients (x) float64 3.0 7.0 11.0 15.0 ... 27.0 31.0 35.0 39.0
polyfit_residuals (x) float64 4.522e-28 9.044e-28 ... 4.07e-27 4.522e-27
In [21]: xr.polyval(coord=x, coeffs=out.assign_coords(degree=out.degree.astype(""int32"")))
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
Cell In[21], line 1
----> 1 xr.polyval(coord=x, coeffs=out.assign_coords(degree=out.degree.astype(""int32"")))
File .../xarray/core/computation.py:1972, in polyval(coord, coeffs, degree_dim)
1968 raise ValueError(
1969 f""Dimension `{degree_dim}` should be a coordinate variable with labels.""
1970 )
1971 if not np.issubdtype(coeffs[degree_dim].dtype, int):
-> 1972 raise ValueError(
1973 f""Dimension `{degree_dim}` should be of integer dtype. Received {coeffs[degree_dim].dtype} instead.""
1974 )
1975 max_deg = coeffs[degree_dim].max().item()
1976 coeffs = coeffs.reindex(
1977 {degree_dim: np.arange(max_deg + 1)}, fill_value=0, copy=False
1978 )
ValueError: Dimension `degree` should be of integer dtype. Received int32 instead.
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1621385466
https://github.com/pydata/xarray/pull/7615#issuecomment-1465261367,https://api.github.com/repos/pydata/xarray/issues/7615,1465261367,IC_kwDOAMm_X85XVh03,14808389,2023-03-12T18:02:53Z,2023-03-12T18:02:53Z,MEMBER,"thanks for the fix and welcome to `xarray`, @Ravenin7","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1620445862
https://github.com/pydata/xarray/issues/7614#issuecomment-1465239918,https://api.github.com/repos/pydata/xarray/issues/7614,1465239918,IC_kwDOAMm_X85XVclu,14808389,2023-03-12T16:19:53Z,2023-03-12T16:19:53Z,MEMBER,"as discussed on discord, the reason for that failure is that current versions of `numba` are incompatible with `numpy>=1.24`. Downgrading to `numpy<1.24` should get the docs to build successfully.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1620412697
https://github.com/pydata/xarray/issues/7266#issuecomment-1460637902,https://api.github.com/repos/pydata/xarray/issues/7266,1460637902,IC_kwDOAMm_X85XD5DO,14808389,2023-03-08T18:16:31Z,2023-03-08T18:16:31Z,MEMBER,closed by #7444,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424
https://github.com/pydata/xarray/pull/7595#issuecomment-1460617219,https://api.github.com/repos/pydata/xarray/issues/7595,1460617219,IC_kwDOAMm_X85XD0AD,14808389,2023-03-08T18:05:54Z,2023-03-08T18:05:54Z,MEMBER,"> Does it still exist?
It does not (I think?): the wiki feature is disabled, and enabling it just creates a blank instance. So I guess if it ever existed it is gone now.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1615570467
https://github.com/pydata/xarray/pull/7444#issuecomment-1460450199,https://api.github.com/repos/pydata/xarray/issues/7444,1460450199,IC_kwDOAMm_X85XDLOX,14808389,2023-03-08T16:22:19Z,2023-03-08T16:23:36Z,MEMBER,"I agree, those do indeed seem unrelated, and I have no idea why the python 3.11 macos CI takes that long to run.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1535387692
https://github.com/pydata/xarray/pull/7590#issuecomment-1460185330,https://api.github.com/repos/pydata/xarray/issues/7590,1460185330,IC_kwDOAMm_X85XCKjy,14808389,2023-03-08T13:51:18Z,2023-03-08T13:51:18Z,MEMBER,pre-commit.ci run,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 1, ""eyes"": 0}",,1612068411
https://github.com/pydata/xarray/pull/7444#issuecomment-1460178545,https://api.github.com/repos/pydata/xarray/issues/7444,1460178545,IC_kwDOAMm_X85XCI5x,14808389,2023-03-08T13:46:19Z,2023-03-08T13:46:19Z,MEMBER,"the docs failure is real, I think we need to update https://github.com/pydata/xarray/blob/821dc24b5f3ed91b843a634bf8513a26046269ef/doc/user-guide/weather-climate.rst#L236 to use the new parameter (not sure how exactly, though)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1535387692
https://github.com/pydata/xarray/issues/7556#issuecomment-1459792052,https://api.github.com/repos/pydata/xarray/issues/7556,1459792052,IC_kwDOAMm_X85XAqi0,14808389,2023-03-08T09:01:53Z,2023-03-08T09:01:53Z,MEMBER,"Since the label exists and the spelling is correct, I *think* the only thing we need to do here is use the appropriate `sphinx` role. To figure out which one, we can either manually search the `intersphinx` registry using
```bash
$ python -m sphinx.ext.intersphinx https://docs.xarray.dev/en/latest/objects.inv | less
```
(which is a bit tedious because that particular section is pretty big, and we need to have `sphinx` installed)
or we can use [`sphobjinv`](https://sphobjinv.readthedocs.io/en/stable/):
```bash
$ sphobjinv suggest -u https://docs.xarray.dev/en/latest/ datetime_component_indexing
Attempting https://docs.xarray.dev/en/latest ...
... no recognized inventory.
Attempting ""https://docs.xarray.dev/en/latest/objects.inv"" ...
... inventory found.
------------------------------------------------------------------------------------------------------------------------------
The intersphinx_mapping for this docset is LIKELY:
(https://docs.xarray.dev/en/latest/, None)
------------------------------------------------------------------------------------------------------------------------------
Project: xarray
Version: 2023.2.1.dev19
7468 objects in inventory.
------------------------------------------------------------------------------------------------------------------------------
1 result found at/above current threshold of 75.
:std:label:`datetime_component_indexing`
```
which helpfully tells us the correct link (though I think we can use `:label:` instead of `:std:label:`)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1598266728
https://github.com/pydata/xarray/issues/7420#issuecomment-1458156140,https://api.github.com/repos/pydata/xarray/issues/7420,1458156140,IC_kwDOAMm_X85W6bJs,14808389,2023-03-07T13:16:47Z,2023-03-07T13:16:47Z,MEMBER,"there's also a few failing `zarr` v3 tests (cc @jhamman):
```
xarray/tests/test_backends.py::TestZarrDirectoryStoreV3::test_write_read_select_write: KeyError: 'var1'
xarray/tests/test_backends.py::TestZarrDirectoryStoreV3FromPath::test_write_read_select_write: KeyError: 'var2'
```
and some unrelated tests that didn't raise errors when we expected them (not sure what causes that, I didn't investigate).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1519784328
https://github.com/pydata/xarray/issues/7420#issuecomment-1458106040,https://api.github.com/repos/pydata/xarray/issues/7420,1458106040,IC_kwDOAMm_X85W6O64,14808389,2023-03-07T12:42:04Z,2023-03-07T12:42:04Z,MEMBER,"the currently failing `pint` tests are an upstream issues (`numpy` dev has changed `amin` and `amax` to become aliases of `min` and `max` instead of the other way around, and `round_` has been deprecated in favor of `round`) and will be fixed by hgrecco/pint#1721","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1519784328
https://github.com/pydata/xarray/pull/7444#issuecomment-1457979204,https://api.github.com/repos/pydata/xarray/issues/7444,1457979204,IC_kwDOAMm_X85W5v9E,14808389,2023-03-07T11:08:07Z,2023-03-07T11:08:07Z,MEMBER,"both the failing upstream-dev CI *and* the failing docs CI seem to be unrelated to this. The `TimeResampleGrouper` seems to do something different from the one in #7561, but I think that's up to that PR to figure out (since we don't yet expose it as public API).
So considering that, how much do you think is needed until we can merge this? And can I help with anything?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1535387692
https://github.com/pydata/xarray/issues/7587#issuecomment-1456139058,https://api.github.com/repos/pydata/xarray/issues/7587,1456139058,IC_kwDOAMm_X85Wyusy,14808389,2023-03-06T13:29:14Z,2023-03-06T13:29:14Z,MEMBER,"thanks, that helps. However, it does not confirm my suspicion since all data variables are already in `float64`, and thus they shouldn't change dtypes. Could you also post the `repr` (either the text or the html repr should be sufficient) of `a`, and maybe also the file type of the file you're loading the dataset from (`ifileFamBulk`)?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1611288905
https://github.com/pydata/xarray/issues/7587#issuecomment-1456063239,https://api.github.com/repos/pydata/xarray/issues/7587,1456063239,IC_kwDOAMm_X85WycMH,14808389,2023-03-06T12:41:24Z,2023-03-06T12:41:49Z,MEMBER,"I can't really tell from the information you posted so far. Could you post the `repr` of `da_fam_bulk` (`print(da_fam_bulk)` or `display(da_fam_bulk)` using `ipython` / `jupyter`, plus maybe a screenshot of the HTML repr if you're in a notebook)?
I do suspect, however, that `da_fam_bulk` has a dtype that is not `float64`, but `where` will use `float64(nan)` as a fill value, casting the entire array to a dtype that has a much higher memory usage.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1611288905
https://github.com/pydata/xarray/issues/7423#issuecomment-1453395303,https://api.github.com/repos/pydata/xarray/issues/7423,1453395303,IC_kwDOAMm_X85WoQ1n,14808389,2023-03-03T11:35:33Z,2023-03-03T15:42:01Z,MEMBER,"I just encountered this one as well. It seems the issue is here: https://github.com/pydata/xarray/blob/43ba095712de12c957e0a4acf956df01d84b2046/xarray/core/variable.py#L1815-L1820 where `fill_value = np.nan` and `dtype = ""int64""`.
As mentioned in https://github.com/numpy/numpy/issues/8017#issuecomment-1155517077, `numpy` now warns instead of silently casting `nan` to `int`.
Can we do anything about that here (besides silencing the warning, but I'm not sure if that actually makes sense), or do we need to lobby for nullable dtypes in `numpy` or a `numpy`-adjacent library?
Edit: as it seems there are at least 4 deferred NEPs (NEPs 12, 24, 25, and 26) on the topic of missing values this might be more tricky than I expected. So I guess that means that we might have to try finding a workaround.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1521368478
https://github.com/pydata/xarray/pull/7442#issuecomment-1453275941,https://api.github.com/repos/pydata/xarray/issues/7442,1453275941,IC_kwDOAMm_X85Wnzsl,14808389,2023-03-03T10:04:19Z,2023-03-03T10:04:19Z,MEMBER,"with the release of `sphinx-book-theme=1.0.0` yesterday we can finally move this forward.
In the process I fixed a few other docs issues so I'll merge this now to avoid having the docs CI fail on `main`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1534634670
https://github.com/pydata/xarray/pull/7555#issuecomment-1443966493,https://api.github.com/repos/pydata/xarray/issues/7555,1443966493,IC_kwDOAMm_X85WES4d,14808389,2023-02-24T16:32:02Z,2023-02-24T16:32:02Z,MEMBER,"don't worry about the commit history, we *always* squash merge","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1597701713
https://github.com/pydata/xarray/pull/7555#issuecomment-1443380118,https://api.github.com/repos/pydata/xarray/issues/7555,1443380118,IC_kwDOAMm_X85WCDuW,14808389,2023-02-24T09:54:22Z,2023-02-24T09:54:22Z,MEMBER,"here's a example of how we solved this before: https://github.com/pydata/xarray/blob/4427eaaf418103eca8786af4d97f3d365cbcba63/xarray/core/dataset.py#L2093-L2094
This is technically the same, except when reading this you don't have to parse the rst link syntax.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1597701713
https://github.com/pydata/xarray/issues/6772#issuecomment-1438733254,https://api.github.com/repos/pydata/xarray/issues/6772,1438733254,IC_kwDOAMm_X85VwVPG,14808389,2023-02-21T16:04:37Z,2023-02-21T16:04:37Z,MEMBER,"Apologies for letting this sit for so long.
The reason for the unexpected behavior seems to be that `mean` is implemented using `sum / count`:
https://github.com/pydata/xarray/blob/21d86450b3cec595c74aa410cbcc367c9c7f8a0a/xarray/core/rolling.py#L176
https://github.com/pydata/xarray/blob/21d86450b3cec595c74aa410cbcc367c9c7f8a0a/xarray/core/rolling.py#L161-L163
where `min_periods` is applied in the `sum` (by masking values where `count < min_periods`).
However, `sum` on rolling objects will fill any missing values with `0` before doing anything else, so when the actual sum is computed `skipna` does not have any effect.
So if you were to set `min_periods=1` you'd get the same result as what you'd expect while `min_periods=3` is what you're seeing.
@pydata/xarray, any idea what to do here? Should we document that passing `skipna` does not have any effect on rolling window sums / means, or would it be better to change the implementation? Or maybe I'm missing something else?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1301023040
https://github.com/pydata/xarray/issues/7546#issuecomment-1438647770,https://api.github.com/repos/pydata/xarray/issues/7546,1438647770,IC_kwDOAMm_X85VwAXa,14808389,2023-02-21T15:09:43Z,2023-02-21T15:09:43Z,MEMBER,"Could you post the output you get? If I try it locally, I get:
```python
In [3]: import xarray as xr
...: import pandas as pd
...: import numpy as np
...:
...: da = xr.DataArray(
...: np.array([1, 2, 3, 1, 2, np.nan]),
...: dims=""time"",
...: coords=dict(
...: time=(""time"", pd.date_range(""01-01-2001"", freq=""M"", periods=6)),
...: labels=(""time"", np.array([""a"", ""b"", ""c"", ""c"", ""b"", ""a""])),
...: ),
...: )
...: da.labels.attrs[""units""] = ""a.u.""
...:
...: ds = xr.Dataset(dict(da=da))
...: ds.attrs[""units""] = ""V""
...: display(ds)
...:
...: m = ds.groupby(""labels"").mean(keep_attrs=True)
...: display(m)
...: display(m.labels) # labels has attribute for units
Dimensions: (time: 6)
Coordinates:
* time (time) datetime64[ns] 2001-01-31 2001-02-28 ... 2001-06-30
labels (time)
Dimensions: (labels: 3)
Coordinates:
* labels (labels) object 'a' 'b' 'c'
Data variables:
da (labels) float64 1.0 2.0 2.0
Attributes:
units: V
array(['a', 'b', 'c'], dtype=object)
Coordinates:
* labels (labels) object 'a' 'b' 'c'
Attributes:
units: a.u.
```
which looks fine to me? But maybe I'm missing something?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1593602847
https://github.com/pydata/xarray/issues/7545#issuecomment-1438625180,https://api.github.com/repos/pydata/xarray/issues/7545,1438625180,IC_kwDOAMm_X85Vv62c,14808389,2023-02-21T14:55:48Z,2023-02-21T14:59:06Z,MEMBER,"It seems that `skipna` has been ignored since #2541 (more than four years ago). While that might have been unintentional at the time I don't think `resample` should have that option, so maybe we should just raise a warning like we do for `keep_attrs` and eventually remove both.
Does this do what you expect?
```python
In [2]: da.resample(time=""A-Dec"").mean(skipna=True)
Out[2]:
array([[6.5]])
Coordinates:
* value (value) int64 0
* time (time) datetime64[ns] 2022-12-31
In [3]: da.resample(time=""A-Dec"").mean(skipna=False)
Out[3]:
array([[nan]])
Coordinates:
* value (value) int64 0
* time (time) datetime64[ns] 2022-12-31
```
Edit: I don't think this is related to #6772, but I'll also have a look at what's wrong there","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1593589979
https://github.com/pydata/xarray/issues/4079#issuecomment-1435715372,https://api.github.com/repos/pydata/xarray/issues/4079,1435715372,IC_kwDOAMm_X85Vk0cs,14808389,2023-02-18T16:51:14Z,2023-02-18T16:51:14Z,MEMBER,"> hmm... would `np.nan` work?
not sure about alignment, but at least `obj.sizes` would break with multiple dims: while it does not compare as equal, the `hash()` of `np.nan` stays constant (same with any other object, I guess).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,621078539
https://github.com/pydata/xarray/issues/4079#issuecomment-1434805981,https://api.github.com/repos/pydata/xarray/issues/4079,1434805981,IC_kwDOAMm_X85VhWbd,14808389,2023-02-17T15:28:07Z,2023-02-17T15:28:07Z,MEMBER,"I'd probably use `itertools.count()` or the `uuid` module to generate globally unique dimension names... something like
```python
class _UnnamedDimensions:
def __init__(self):
self.dimension_names = (f""unnamed_dim_{number}"" for number in itertools.count())
def __call__(self, n):
return list(itertools.islice(dimension_names, None, n))
unnamed_dimensions = _UnnamedDimensions()
```
or using `uuid` (probably overkill):
```python
def unnamed_dimensions(n):
return [uuid.uuid4() for _ in range(n)]
```
you'd use it like this:
```python
d1 = xr.DataArray(data=[1, 2], dims=unnamed_dimensions(1))
d2 = xr.DataArray(data=[[1, 2]], dims=unnamed_dimensions(2))
```
which would make ""unnamed"" a bit more explicit.
Edit: that's probably not so different from what you meant with `d1_i`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,621078539
https://github.com/pydata/xarray/pull/7442#issuecomment-1430104788,https://api.github.com/repos/pydata/xarray/issues/7442,1430104788,IC_kwDOAMm_X85VParU,14808389,2023-02-14T17:19:09Z,2023-02-14T17:19:09Z,MEMBER,as expected that environment is not solvable because `sphinx-book-theme` didn't have a release since the bump of the `sphinx` version,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1534634670
https://github.com/pydata/xarray/pull/7442#issuecomment-1430090774,https://api.github.com/repos/pydata/xarray/issues/7442,1430090774,IC_kwDOAMm_X85VPXQW,14808389,2023-02-14T17:09:25Z,2023-02-14T17:09:25Z,MEMBER,"I think we should pin `sphinx-book-theme` to some appropriate version, right now we have `0.0.41`, which is about two years old (and is probably the last version that does not contain the upper bound on `sphinx`)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1534634670
https://github.com/pydata/xarray/issues/7486#issuecomment-1412396521,https://api.github.com/repos/pydata/xarray/issues/7486,1412396521,IC_kwDOAMm_X85UL3Xp,14808389,2023-02-01T17:00:14Z,2023-02-01T17:00:14Z,MEMBER,"thanks, that makes sense to me. I think that rules out option 3, so now we only need to decide whether we remove only the data url or the entire section (personally, I would lean towards the latter).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562408536
https://github.com/pydata/xarray/issues/7486#issuecomment-1412214395,https://api.github.com/repos/pydata/xarray/issues/7486,1412214395,IC_kwDOAMm_X85ULK57,14808389,2023-02-01T15:07:15Z,2023-02-01T15:07:15Z,MEMBER,"1 is the status quo (minus the removal of the data server url): the cells are set to ""raw"", so they are not run. We don't want to hit the server during CI anyways, as hitting the server would slow down the docs build too much.
It seems like there's at least two people who tried to follow the subsetting (or otherwise play with the raw data), so the section does have some value. However, I don't know how this compares to the burden of maintaining it, especially since we don't run it in CI.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562408536
https://github.com/pydata/xarray/issues/7493#issuecomment-1409383538,https://api.github.com/repos/pydata/xarray/issues/7493,1409383538,IC_kwDOAMm_X85UAXxy,14808389,2023-01-30T21:39:23Z,2023-01-30T21:54:20Z,MEMBER,"we are casting everything back to `datetime64[ns]` when creating xarray objects, for example, so the only way to even get a non-nanosecond datetime variable is (or was, we might have fixed that?) through the zarr backend (though that would / might fail elsewhere).
@spencerkclark knows much more about this, but in any case we're aware of the change and are working it (see e.g. #7441). (To be fair, though, at the moment it is mostly Spencer who's working on it, and he seems to be pretty preoccupied.)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480
https://github.com/pydata/xarray/issues/7486#issuecomment-1409066939,https://api.github.com/repos/pydata/xarray/issues/7486,1409066939,IC_kwDOAMm_X85T_Ke7,14808389,2023-01-30T17:56:04Z,2023-01-30T17:56:04Z,MEMBER,"don't we do that already? As far as I can tell, the url is there to explain where we got the data from and what preprocessing was done. Unless I'm missing something?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562408536
https://github.com/pydata/xarray/issues/7486#issuecomment-1408703594,https://api.github.com/repos/pydata/xarray/issues/7486,1408703594,IC_kwDOAMm_X85T9xxq,14808389,2023-01-30T14:17:55Z,2023-01-30T14:17:55Z,MEMBER,"the data server is out of our control, so we can't fix this ourselves, unfortunately.
We might be able to look for a different server for that model, but I don't know enough about the model to do that myself. Any ideas, @pydata/xarray?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562408536
https://github.com/pydata/xarray/issues/7487#issuecomment-1408687131,https://api.github.com/repos/pydata/xarray/issues/7487,1408687131,IC_kwDOAMm_X85T9twb,14808389,2023-01-30T14:07:12Z,2023-01-30T14:07:12Z,MEMBER,"this looks like a duplicate of #7486. Closing, but feel free to follow the discussion there.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1562510372
https://github.com/pydata/xarray/issues/7079#issuecomment-1404127967,https://api.github.com/repos/pydata/xarray/issues/7079,1404127967,IC_kwDOAMm_X85TsUrf,14808389,2023-01-25T19:32:12Z,2023-01-25T19:37:14Z,MEMBER,`iris` has the pin in their package metadata,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1385031286
https://github.com/pydata/xarray/issues/7270#issuecomment-1400487847,https://api.github.com/repos/pydata/xarray/issues/7270,1400487847,IC_kwDOAMm_X85Teb-n,14808389,2023-01-23T14:56:51Z,2023-01-23T14:56:51Z,MEMBER,should this have been closed by #7283?,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440494247