This PR makes it easier to trigger the upstream CI and creates a mypy test for upstream as well, but only when adding this label so that it doesn't mess with the scheduled runs and those results.

Noticed the need in #7786.

Matplotlib has started to support typing in main (https://github.com/matplotlib/matplotlib/issues/20504) and mypy is throwing a few errors:

Some guidance how to solve these:

• [xy]ticks in mpl is currently overly narrowly type hinted because I was following the docstring, but I agree that ArrayLike is a better type hint for that, plan on updating (including the docstring) upstream
• [xy]lim originally neglected the case of passing set_xlim((min, max)) as a tuple, but that has been updated. xarray has that type hinted as array like, but mpl has it hinted as a 2-tuple (I think it is currently still of floats, but may be expanded as we more directly address units/categoricals/etc). Willing to debate here, but my starting position is that the "exactly 2 values" is valuable info here, and I think tuple is the only way to do that.
• get_renderer is not actually available on all of our backends, we should maybe see if there is a more preferred way of doing what you are doing here that will work for all backends, but haven't looked into it too closely.
• Module has no attribute <colormap> is another instance of dynamically generated behavior which can't be statically type checked (elegantly, at least), can probably be replaced by mpl.colormaps["<colormap>"] in many cases, which is statically typecheckable
• Anything to do with 3D Axes is not type hinted, perhaps ignore for now (or help us get that type hinted adequately, but it is relatively low priority currently)
• Module has no attribute "dates" we don't currently type hint dates/units things, but it is on my mind, not sure yet if it will be in first release or not though (may at least put a placeholder that gets rid of this error, but treats everything as "Any").

Originally posted by @ksunden in https://github.com/pydata/xarray/issues/7787#issuecomment-1523743471

The suggestion from mpl (specifically @tacaswell) was to use constrained layout for the purpose that xarray currently uses get_renderer, this will ensure that the facetgrid works with all mpl backends.

Originally posted by @ksunden in https://github.com/pydata/xarray/issues/7787#issuecomment-1528091492

I'm also relatively sure that if you are willing to put a floor on the version of Matplotlib you support get_window_extent will use it's internally cached renderer (and when we make it uniformly optional we also fixed the cache invalidation logic).

Originally posted by @tacaswell in https://github.com/pydata/xarray/issues/7787#issuecomment-1528096647

I saw dask has started using absolute imports in https://github.com/dask/dask/pull/8796. I find it much more readable and there's a nice pre-commit for it as well.

Easiest way to deal with the merge conflicts is probably to just accept your changes and let pre-commit fix them afterwards.

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

Self should be as permissive as possible until it works properly.

Using Any instead of TypeVar avoids errors like these: C:\users\j.w\documents\github\xarray\xarray\plot\facetgrid.py:462: error: Incompatible return value type (got "FacetGrid", expected "Self")

xref: #6923

Make #6239 cleaner by running pyupgrade separately.

pyupgrade fixes typing only if from __future__ import annotations has been manually added to the file. Could probably do this in other files as well.

xref: #6244

• [x] Benchmark from #659
• [x] Tests added
• [x] Passes pre-commit run --all-files

Dask released 2.24 around august 22 2020: https://github.com/dask/dask/releases/tag/2.24.0

• [x] May help fixing errors in #5571
• [x] Passes pre-commit run --all-files
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Remove some compatibility code that doesn't seem necessary anymore.

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

Show the printed and total number of variables in the repr.

• [x] Passes isort . && black . && mypy . && flake8

```python import numpy as np import xarray as xr

a = np.arange(0, 15) b = np.core.defchararray.add("long_variable_name", a.astype(str)) c = np.arange(0, 25) d = np.core.defchararray.add("attr_", c.astype(str)) e = {k: 2 for k in d} coords = dict(time=da.array([0, 1])) data_vars = dict() for v in b: data_vars[v] = xr.DataArray( name=v, data=np.array([0, 1]).astype(bool), dims=["time"], coords=coords, ) ds1 = xr.Dataset(data_vars) ds1.attrs = e

The repr now shows how many attributes in total there are:

print(ds1) Out[10]: <xarray.Dataset> Dimensions: (time: 2) Coordinates: * time (time) int32 0 1 Data variables: (12/15) long_variable_name0 (time) bool False True long_variable_name1 (time) bool False True long_variable_name2 (time) bool False True long_variable_name3 (time) bool False True long_variable_name4 (time) bool False True long_variable_name5 (time) bool False True ... long_variable_name9 (time) bool False True long_variable_name10 (time) bool False True long_variable_name11 (time) bool False True long_variable_name12 (time) bool False True long_variable_name13 (time) bool False True long_variable_name14 (time) bool False True Attributes: (12/25) attr_0: 2 attr_1: 2 attr_2: 2 attr_3: 2 attr_4: 2 attr_5: 2 ... attr_19: 2 attr_20: 2 attr_21: 2 attr_22: 2 attr_23: 2 attr_24: 2 ```