issues

Follow up to https://github.com/pydata/xarray/pull/8586

I believe this was missed in v2023.08.0 (Aug 18, 2023).

xref: https://github.com/conda-forge/xarray-feedstock/pull/97

• [x] towards understanding #7079
• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

• [x] Closes #7835

Thanks @pierre-manchon for the report!

Previously, the first context manager in this test was closed before accessing the data. This resulted in key errors when trying to access the opened dataset.

• [x] Fixes the Zarr V3 parts of https://github.com/pydata/xarray/issues/7707

This updates our minimum versions based on our 24/18/12 month policy.

Details are shown below.

• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

This PR add's the to_zarr method to Xarray's DataArray objects. This allows users to roundtrip named and unnamed DataArrays to Zarr without having to first convert to a Dataset.

• [x] Closes #7692
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

• [x] Closes #7686
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

• [x] Closes #7624

This switches our primary linter to Ruff. As adervertised, Ruff is very fast. Plust we get the benefit of using a single tool that combines the previous functionality of pyflakes, isort, and pyupgrade.

• [x] Closes https://twitter.com/TEGNicholasCode/status/1613226956887056385
• [x] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

cc @max-sixty, @TomNicholas

This should fix our doc build.

• [x] Closes #7434

This PR finally deprecates the PyNIO backend. PyNIO is technically in maintenance mode but it hasn't had any maintenance in 4+ years. Its conda packages cannot be installed in any of our test environments. I have added a future warning to the NioDataStore.__init__ method and noted the deprecation in the IO docs.

• [x] Closes #4491
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

The min versions checks are failing in #6475. This hopefully fixes those failures.

• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

In light of the new splash page site (https://xarray.dev), this PR updates the documentation site's index page to simply provide pointers to key parts of Xarray's documentation.

TODOs: - [x] Get feedback on the content and layout - [x] Update the Icon SVGs (these along with the layout were borrowed, in part, from Pandas).

cc @andersy005, @rabernat

This adds an encoding option to Xarray's to_dict methods.

• [x] Closes #6634
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

This PR updates our step-by-step guide for releasing Xarray. It makes a few minor changes to account for #6206 and officially documents the switch to CALVER. This should be clearly documented in whats-new.rst as part of the first release utilizing CALVER.

Also, note that this should probably wait until we make the 0.20.1 patch release.

• [x] Closes #6176, #6206
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

We are in the process of moving our documentation url from https://xarray.pydata.org to https://docs.xarray.dev. This PR makes that change throughout the documentation. Additionally, I corrected some broken links and fixed some missing https urls in the process.

cc @andersy005

• [x] Closes #4139
• [x] Tests added
• [x] Passes isort -rc . && black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @scottyhq and @martindurant

xref: https://github.com/pangeo-data/pangeo-datastore/issues/109

This adds a new file to the root of the Xarray repository, CITATION.cff. GitHub recently added support for citation files and adding this file will add a UI feature to the Xarray GitHub repo.

The author list is based on the latest Zenodo release (0.20.1) and I did my best to find everyone's ORCIDs.

• [x] Passes pre-commit run --all-files

cc @pydata/xarray

In this PR, I'm experimenting with using the entrypoints package to support 3rd party backends. This does not attempt to solidify the API for what the store is, I feel like that should happen in a second PR. Here's how it would work...

In @rabernat's xmitgcm package, there is a _MDSDataStore that inherits from xarray.backends.common.AbstractDataStore. To allow reading mds datasets directly in xarray.open_dataset, xmitgcm would add the following lines to its setup.py file:

python setup( ... entry_points={ 'xarray.backends': [ 'mds = xmitgcm.mds_store:_MDSDataStore', ... ] } )

Xarray would then be able to discover this backend at runtime and users could use the store directly in open_dataset calls like this:

python ds = xr.open_dataset('./path/to/file.mds', engine='mds', backend_kwargs={...})

Note: I recognize that xmitgcm.open_mdsdataset has a bunch of other user options that I'm likely ignoring here but this is meant just as an illustration.

Now a list of caveats and things to consider:

1. I have only done this for open_dataset, not for to_netcdf. We may want to consider more generic serialization method that allows for plug-able writers.
2. open_dataset has some special handling for some readers (lock and group selection, file-like objects, etc.). We should work toward moving as much of that logic into the Store objects as possible.
3. We should decide what to do when a 3rd party plugin conflicts with an existing backend. For example, someone could include an entrypoint with the key of netcdf4.

• [x] Partially closes #1970
• [ ] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Fixes #3851
• [x] Tests added
• [x] Passes isort -rc . && black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1850

We've recently released Xpublish. This PR adds the project to the _related-projects` page in the Xarray documentation. To find out more about Xpublish, check out the docs or the release announcement blogpost.

• [x] Closes #3563
• [ ] Tests added
• [ ] Passes black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Toward https://github.com/pydata/xarray/issues/3380#issuecomment-539224341
• [x] Passes black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

See below for inline comments where I could use some input from @shoyer and @crusaderky

• [x] Closes #3377
• [x] Tests added
• [x] Passes black . && mypy . && flake8
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1571
• [x] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #2744
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1910
• [x] Tests added

xref: #2683

This is passing in my local test environment. We'll see on CI...

• [x] Closes #535
• [x] Tests added

As described in #2683, our test suite is failing on Travis with an unfortunate segfault. For now, I've just taken rasterio (and therefore GDAL) out of the offending environment. I'll use this PR to test a few other options.

cc @max-sixty

• [x] Closes #2683
• [ ] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

This dev build is failing due to problems with bottlenecks setup script. Generally, the bottleneck package seems to be missing some maintenance effort so until a new release is issued, I don't think we need to be testing against its dev state.

• [x] Closes #1109

xref: #2661

• [x] Closes #697
• [x] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Improved error message for invalid encodings.

• [x] Closes #2728
• [ ] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

I was feeling particularly zealous today so I decided to see what it would take to strip out all the Python 2 compatibility code in xarray. I expect some will feel its too soon to merge this so I'm mostly putting this up for show-and-tell and to highlight some of the knots we've tied ourselves into over the years.

• [x] Closes #1876
• [ ] Tests added
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

This is a WIP. I expect the CI changes to take a few iterations.

• [x] Closes #1876
• [x] Tests added
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Just adding a full environment for python 3.7.

• [x] Extends #2271
• [x] Tests added

• [x] Tests added
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

In working on an xarray/dask tutorial, I've come to realize we eagerly load the tutorial datasets in xarray.tutorial.load_dataset. I'm going to just say that I don't think we should do that but I could be missing some rational. I didn't open an issue so please feel free to share thoughts here.

One option would be to create a new function (xr.tutorial.open_dataset) that does what I'm suggesting and then slowly deprecate tutorial.load_dataset. Thoughts?

xref: https://github.com/dask/dask-examples/pull/51

Following up on #2271. This switches the set language in our Travis-CI config from "python" to "generic". Since we don't use any of the Travis Python utilities, we didn't really need the python setting and the generic setting gives a few benefits:

• smaller base image which should give a bit faster spin-up time

• build matrix without reliance on python version, instead we just point to the conda environment file

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

• [x] Tests added
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [ ] Closes #xxxx (remove if there is no corresponding issue, which should only be the case for minor changes)
• [ ] Tests added (for all bug fixes or enhancements)
• [ ] Tests passed (for all non-documentation changes)
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

Xarray is now a fiscally sponsored project of NumFOCUS. This PR adds a few blurbs of text highlighting that on the main readme and index page of the docs.

TODO: - Update flipcause to xarray specific donation page

followup PR fixing two small typos in my previous PR.

• [x] Closes #2278
• [x] Tests added
• [ ] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #2238
• [ ] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] closes #2200, closes #1829, closes #2203
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

This updates the following minimum versions:

• numpy: 1.11 (Mar 27, 2016) --> 1.12 (Jan 15, 2017)
• pandas: 0.18 (Mar 11, 2016) --> 0.19 (Oct 2, 2016)
• dask: 0.9 (May 10, 2016) --> 0.16

and drops our tests for python 3.4.

• [x] Closes #2225
• [x] Tests added
• [x] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #2121
• [x] Tests added
• [x] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @rsignell-usgs

• [x] Closes #2134
• [x] Tests added
• [x] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1300 (in a more portable way)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

This eliminates the need to edit setup.py before / after release and is a nice step towards simplifying xarray's release process.

• [x] Closes #2140 ~- [ ] Tests added (for all bug fixes or enhancements)~
• [ ] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @spencerkclark and @shoyer

review of this can wait until after #1800 is merged.

• [x] Closes #1784
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

cc @mrocklin

• [x] Closes #1981
• [x] Tests added
• [x] Tests passed
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

I'm sharing this in the hopes of getting comments from @mrocklin and @pydata/xarray.

What this does:

• implements a dask.bag map/apply on the xarray open_dataset and preprocess steps in open_mfdataset
• adds a new parallel option to open_mfdataset
• provides about a 40% speedup in opening a multifile dataset when using the distributed scheduler (I tested on 1000 netcdf files that took about 9 seconds to open/concatenate in the default configuration)

What it does not do (yet):

• check that autoclose=True when multiple processes are being use (multiprocessing/distributed scheduler)
• provide any speedup with the multiprocessing backend (I do not understand why this is)

Benchmark Example

```Python In [1]: import xarray as xr ...: import dask ...: import dask.threaded ...: import dask.multiprocessing ...: from dask.distributed import Client ...:

In [2]: c = Client() ...: c ...: Out[2]: <Client: scheduler='tcp://127.0.0.1:59576' processes=4 cores=4>

In [4]: %%time ...: with dask.set_options(get=dask.multiprocessing.get): ...: ds = xr.open_mfdataset('../test_files/test_netcdf_*nc', autoclose=True, parallel=True) ...: CPU times: user 4.76 s, sys: 201 ms, total: 4.96 s Wall time: 7.74 s

In [5]: %%time ...: with dask.set_options(get=c.get): ...: ds = xr.open_mfdataset('../test_files/test_netcdf_*nc', autoclose=True, parallel=True) ...: ...: CPU times: user 1.88 s, sys: 60.6 ms, total: 1.94 s Wall time: 4.41 s

In [6]: %%time ...: with dask.set_options(get=dask.threaded.get): ...: ds = xr.open_mfdataset('../test_files/test_netcdf_*nc') ...: CPU times: user 7.77 s, sys: 247 ms, total: 8.02 s Wall time: 8.17 s

In [7]: %%time ...: with dask.set_options(get=dask.threaded.get): ...: ds = xr.open_mfdataset('../test_files/test_netcdf_*nc', autoclose=True) ...: ...: CPU times: user 7.89 s, sys: 202 ms, total: 8.09 s Wall time: 8.21 s

In [8]: ds Out[8]: <xarray.Dataset> Dimensions: (lat: 45, lon: 90, time: 1000) Coordinates: * lon (lon) float64 0.0 4.045 8.09 12.13 16.18 20.22 24.27 28.31 ... * lat (lat) float64 -90.0 -85.91 -81.82 -77.73 -73.64 -69.55 -65.45 ... * time (time) datetime64[ns] 1970-01-01 1970-01-02 1970-01-11 ... Data variables: foo (time, lon, lat) float64 dask.array<shape=(1000, 90, 45), chunksize=(1, 90, 45)> bar (time, lon, lat) float64 dask.array<shape=(1000, 90, 45), chunksize=(1, 90, 45)> baz (time, lon, lat) float32 dask.array<shape=(1000, 90, 45), chunksize=(1, 90, 45)> Attributes: history: created for xarray benchmarking

```

• [x] Closes #1464
• [x] Tests added
• [x] Tests passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Right now, I've just modified the dask distributed integration tests so we can all see the failing tests.

I'm happy to push this further but I thought I'd see if either @shoyer or @mrocklin have an idea where to start?

• [x] Closes #1979 and #1955
• [x] Tests added
• [x] Tests passed

• [x] Closes #1920
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented: see #1920

• [x] Closes #1937
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Thanks @fujiisoup for the report.

• [x] Closes #640
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This is something we've talked about for a while and I'm capitalizing on a moment of inspiration. Full disclosure, I've taken most of this from Pandas and edited it just where it makes sense for Xarray.

If others would like specific changes to this, please comment only on doc/contributing.rst, ~CONTRIBUTING.md is auto generated with pandoc~. @pydata/xarray, feel free to push directly to this branch if there are larger edits you'd like to add.

• [x] Helps with #1084
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

I've added a temporary travis build with the master branch of netcdftime. After a while, we can probably remove that.

This is helping us move towards https://github.com/Unidata/netcdf4-python/issues/601 and #1252

cc @jswhit and @spencerkclark

• [x] Closes #1894
• [ ] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @mrocklin

• [x] Closes #1898 (remove if there is no corresponding issue, which should only be the case for minor changes)
• [x] Tests added (for all bug fixes or enhancements)
• [ ] Tests passed (for all non-documentation changes)
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

• [x] Closes #1830 (remove if there is no corresponding issue, which should only be the case for minor changes)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1867
• [x] Tests passed (for all non-documentation changes)

• [x] Closes #https://github.com/pangeo-data/pangeo/issues/48
• [x] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Passes git diff upstream/master **/*py | flake8 --diff (remove if you did not edit any Python files)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

This is building on top of #1799. Based on the suggestion from @alimanfoo in https://github.com/pangeo-data/pangeo/issues/48#issuecomment-353807691, I have reworked the handling of attributes in the zarr backend. There is more to do here, particularly in the set_dimensions arena but this is giving almost a 2x speedup in writing to GCP.

cc @rabernat, @mrocklin and @alimanfoo

• [x] Closes #1813 ~[ ] Tests added~
• [x] Tests passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API (remove if this change should not be visible to users, e.g., if it is an internal clean-up, or if this is part of a larger project that will be documented later)

• [x] Closes #1631
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Rough draft of interpolate method for filling of arbitrary nans.

cc @darothen

• [x] Closes #1798
• [ ] Tests added (ideas for how to test that load is not called? Regression tests from #1609 are passing)
• [x] Tests passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff (remove if you did not edit any Python files)
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Tests passed (for all non-documentation changes)
• [x] Passes git diff upstream/master **/*py | flake8 --diff

• [x] Closes #1766
• [ ] Tests added (for all bug fixes or enhancements)
• [x] Tests passed (for all non-documentation changes)
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1257
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

This is a very bare bones addition of the asv benchmarking tool to xarray. I have added four very rudimentary benchmarks in the dataset_io.py module.

Usage of asv is pretty straightforward but I'll outline the steps for those who want to try this out: cd xarray conda install asv -c conda-forge asv run # this will install some conda environments in ./.asv/envs asv publish # this collates the results asv preview # this will launch a web server so you can visually compare the tests

Before I go any further, I want to get some input from @pydata/xarray on what we want to see in this PR. In previous projects, I have found designing tests after the fact can end up being fairly arbitrary and I want to avoid that if at all possible. I'm guessing that we will want to focus our efforts for now on I/O and dask related performance but how we do that is up for discussion.

cc @shoyer, @rabernat, @MaximilianR, @Zac-HD

• [x] Closes #1684
• [x] Tests added / passed
• [x] Passes git diff upstream/master **/*py | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

xref: #1674

cc @shoyer, @mrocklin

• [x] Closes #1652
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This first commit just includes the fixes for the warnings issued in our unit tests. I've temporarily added -W error to the travis builds so we can see the warnings/errors for all environments. Next step is to address the warnings in the xarray code itself.

• [x] xref #986
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This PR adds a new module level function xr.show_versions() and a new Github Issue Template to help with debugging user issues. Hopefully, we stop having to ask "what version of dask are you using?" Functionality is copied from pandas.

• [x] Closes #1655
• [x] Tests added / passed

• [x] Closes #1215
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

~TODO: Additional tests needed to verify this works for all the write backends and that the correct errors are raised when dims are different between writes.~

• [x] Closes #1633
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff

This is particularly helpful when using open_mfdataset with a list of files. For example:

Current behavior (unclear which file is causing open_dataset to choke): ```Python-traceback In [2]: xr.open_mfdataset(['foo.nc', 'bar.nc'], engine='netcdf4')

OSError Traceback (most recent call last) <ipython-input-2-12b24f38f025> in <module>() ----> 1 xr.open_mfdataset(['foo.nc', 'bar.nc'], engine='netcdf4')

...

/Users/jhamman/Dropbox/src/xarray/xarray/backends/netCDF4_.py in _open_netcdf4_group(filename, mode, group, kwargs) 183 import netCDF4 as nc4 184 --> 185 ds = nc4.Dataset(filename, mode=mode, kwargs) 186 187 with close_on_error(ds):

netCDF4/_netCDF4.pyx in netCDF4._netCDF4.Dataset.init()

netCDF4/_netCDF4.pyx in netCDF4._netCDF4._ensure_nc_success()

OSError: No such file or directory ```

And the new behavior ```Python-traceback In [2]: xr.open_mfdataset(['foo.nc', 'bar.nc'], engine='netcdf4')

...

/Users/jhamman/Dropbox/src/xarray/xarray/backends/netCDF4_.py in _open_netcdf4_group(filename, mode, group, kwargs) 186 ds = nc4.Dataset(filename, mode=mode, kwargs) 187 except OSError as e: --> 188 raise OSError("Error opening %r" % filename, e) 189 190 with close_on_error(ds):

OSError: [Errno Error opening '/Users/jhamman/Dropbox/src/xarray/foo.nc'] No such file or directory

• [x] Closes #1636
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

(these tests will fail until conda-forge get's an updated version of h5netcdf)

• [x] Closes #1605
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• ~[ ] Fully documented, including whats-new.rst for all changes and api.rst for new API~

cc @darothen

• [x] Closes #1606
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1531
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

As @crusaderky pointed out, just moving the @requires_pynio decorator inside the TestPyNio class seems to fix the problems described in #1531. It looks like requires_pynio is nullifying CFEncodedDataTest, Only32BitTypes, TestCase in addition to TestPyNio, hence the propagation.

This PR also includes a cleanup of tests/__init__.py.

• [x] Closes #1279
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @shoyer, @darothen, @arbennett, @vnoel

• [x] Closes #1090
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff

The fix for this issue went into dask v.0.13 (Jan 2, 2017).

xrefs https://github.com/dask/dask/pull/1799, https://github.com/dask/dask/issues/1764

• [x] Closes #1555
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1120
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1523
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @crusaderky - putting this up in case its useful to you.

I'm frankly not sure if my tests are doing what they need to but everything seems to be playing nicely.

• [x] Closes #1410
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1438, Fixes #1299
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @gerritholl

• [x] Fixes #1405, Closes #1406
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

cc @gerritholl

…h coords dict and not dims

• [x] Closes #1197
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] Closes #1524
• [x] Tests added / passed
• [x] Passes git diff upstream/master | flake8 --diff
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

• [x] closes #931 and #290 (already closed)

A few doc updates to reflect the newly published status of our xarray paper.

Bottleneck added support for rolling variance calculations (bn.move_var) as well as a few other functions in version 1.1. This PR conditionally uses those new functions, when they are available.

• [x] closes #1276
• [x] tests added / passed
• [x] passes git diff upstream/master | flake8 --diff
• [x] whatsnew entry

cc @shoyer and @d-chambers

• [ ] closes #xxxx
• [ ] tests added / passed
• [ ] passes git diff upstream/master | flake8 --diff
• [ ] whatsnew entry

This is just a quick PR to clean up a few style violations that have crept in. I also removed a number of unused imports.

• [ ] closes #xxxx
• [x] tests passed
• [x] passes git diff upstream/master | flake8 --diff
• [ ] whatsnew entry

Quick update to docs to use latest zenodo doi

Add Dataset.encoding attribute and support unlimited dimensions for scipy/netcdf4 backends.

closes #992

This PR adds the quantile method to the DataArray. There may be a way to better fit this in with .apply or reduce it wasn't immediately clear to me how to do that. It uses np.nanpercentile under the hood so this shouldn't be expected to work well with dask. The main advantage to this method, over using apply(np.nanpercentile) is the handling of the quantile coordinate.

example usage:

```Python In [12]: x = np.random.random(size=(2, 3, 800))

In [13]: da = xr.DataArray(x, dims=('x', 'y', 'time'))

In [14]: da.quantile([1, 5, 10, 25, 50, 75, 90, 95, 99], dim='time', interpolation='lower') Out[14]: <xarray.DataArray (quantile: 9, x: 2, y: 3)> array([[[ 0.00835474, 0.01126747, 0.00778847], [ 0.00803924, 0.00919259, 0.01150164]],

   [[ 0.04902814,  0.05346976,  0.04493341],
    [ 0.04236611,  0.05273082,  0.05858802]],

   [[ 0.09370776,  0.09976448,  0.09256707],
    [ 0.08943787,  0.09331907,  0.08832309]],

   [[ 0.25416402,  0.22577298,  0.24407393],
    [ 0.25386087,  0.23052584,  0.24621966]],

   [[ 0.534169  ,  0.46017551,  0.49817391],
    [ 0.50968059,  0.49427688,  0.51573855]],

   [[ 0.76633412,  0.73405412,  0.77210754],
    [ 0.76759837,  0.74243892,  0.76703357]],

   [[ 0.90832116,  0.89495854,  0.91818434],
    [ 0.91492771,  0.88063773,  0.91416636]],

   [[ 0.95260527,  0.95132871,  0.95979701],
    [ 0.95988286,  0.93137055,  0.95941658]],

   [[ 0.98597133,  0.98883232,  0.99013424],
    [ 0.98951238,  0.97550784,  0.99224201]]])

Coordinates: * quantile (quantile) float64 1.0 5.0 10.0 25.0 50.0 75.0 90.0 95.0 99.0 o x (x) - o y (y) - ```

closes #303 fixes #561