xarray 0.11 release

[shoyer]

We should really get a release candidate out soon for xarray 0.11, which will fix a lot of IO issues with dask (e.g., https://github.com/pydata/xarray/issues/2503).

Deprecation cycles to finish first:

• [x] Iterating over a Dataset iterates only over its data_vars #884
• [x] "in" operator does not work as expected on DataArray dimensions #1267
• [x] remove .T as an alias for .transpose() #1232
• [x] remove old resample syntax

Deprecation cycles to start (optional)

• [x] Deprecate inplace methods #1756

These were everything tagged with the "0.11" milestone.

@pydata/xarray anything else to add?

[dcherian]

• [x] #2444 is a small bugfix for facetgrid that's ready for review.

These PRs seem to be almost done (it'd be nice to get some of these in):

2470 (fill_value in shift)

2449 (to_iris, from_iris)

2207 (something about chunksizes)

2415 (test for 1D object indexing)

2413 (positional arguments for groupby apply)

[rabernat]

Would be nice to get #2487 finished before release. (zarr chunking bug)

[max-sixty]

I'll do Iterating over a Dataset iterates only over its data_vars

[dcherian]

Oooh we're supposed to remove .T as an alias for .transpose() #1232. finally!

[jhamman]

Would it make sense to add a deprecation warning for Python2 users in this release (xref #1876). Chances are, 0.12 will come after Jan-2019 when we're slated to drop Python2 support.

[shoyer]

Would it make sense to add a deprecation warning for Python2 users in this release (xref #1876). Chances are, 0.12 will come after Jan-2019 when we're slated to drop Python2 support.

I agree, this will probably be the last major xarray release with Python 2 support. But I don't think there's much to be gained by adding a warning -- Python 2 users know the end is near.

[jhamman]

Python 2 users know the end is near.

Based on recent experience, I'm not quite as confident here 😄

[fmaussion]

Did any other library have a warning for this? I think that if we follow the lead of ipython, matplotlib and https://python3statement.org/ then all we have to do is make 0.12 non-installable on py2, and py2 users will stick to 0.11 ad vitam æternam.

It would be quite mean to have them listen to a warning all the time they import xarray on top of that :smile:

ipython docs have a big warning banner though

[shoyer]

@spencerkclark and other climate scientists: should we switch the default behavior to use cftime for non-standard calendars in 0.11? (see https://github.com/pydata/xarray/issues/2437)

[spencerkclark]

should we switch the default behavior to use cftime for non-standard calendars in 0.11?

I would be +1 on this; as evidenced by #2437 it has become increasingly confusing/error-prone to use non-standard/out-of-range dates without CFTimeIndex enabled. That said, since not everything is enabled yet (namely resample and plotting), I'd be sympathetic to those who would rather wait a bit longer.

[shoyer]

@spencerkclark I also think this is probably a good idea. If you have time, it would be great if you could put together a PR to switch the behavior.

[spencerkclark]

@shoyer sure thing, barring feedback from others, I'll try and put a PR together tomorrow.

[shoyer]

Another deprecation cycle to finish would be the old resample() syntax.

[dcherian]

(commented on wrong issue)

[shoyer]

Another deprecation cycle to finish would be the old resample() syntax.

I got started on this one...

[jhamman]

I'm observing that our checklist seems to be complete. Are we blocked on any outstanding issues?

[shoyer]

see https://github.com/pydata/xarray/pull/2548 for some minor
reorganization of the release notes

On Tue, Nov 6, 2018 at 7:57 PM Joe Hamman [e-mail] wrote:

I'm observing that our checklist seems to be complete. Are we blocked on
any outstanding issues?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pydata/xarray/issues/2505#issuecomment-436464907, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABKS1n0lnPnS0XcLgOvEro2PN5JoGTIMks5usjAHgaJpZM4X4V2i
.

[shoyer]

I just tagged the release and uploaded it to pypi. RTD and conda forge should follow soon automatically.

[jhamman]

Thanks @shoyer!

[jhamman]

Related and something I could use feedback from @pydata/xarray on: should we drop optional deps from the conda-forge build: https://github.com/conda-forge/xarray-feedstock/pull/37

[shoyer]

Generally I always favor the most granular dependency specifications, but this seems like something conda-forge could decide as a matter of policy. If they don't want to rule on a general policy, then yes let's drop optional conda deps to match pypi.