Peter Hill

xarray 2022.10 causes further slow down of the tests -- deep copying seems to have gotten x20 slower See, e.g. https://github.com/boutproject/xBOUT/pull/252#issuecomment-1282672540 > For TestPlot::test_region_disconnecteddoublenull specifically, it might be worth splitting...

The deep copying is more expensive because it's now copying DataArrays in attributes -- and the Regions have two or three nested levels of this. So ways of removing that...

It seems that prior to 2022.10, deep copying didn't deep copy the attributes (and therefore regions?), so presumably a shallow copy should be fine now? I switched some deep copies...

Is it just a matter of putting this line: https://github.com/boutproject/xBOUT/blob/467016021b8650e8e107936f8aa487cd5168eb97/xbout/load.py#L746 after the checks on `filepaths` in that function?

This is because there's no built wheel for 1.4.2 on py3.8, and building netcdf4 from source is a little painful. We should drop support for py3.8 entirely (see [NEP 29](https://numpy.org/neps/nep-0029-deprecation_policy.html)),...

Might be better to just move all the tests to a top-level directory so they're not installed at all?

For finding the packages, it's trivial to just have `packages = ["xbout"]` as there's only the one package to install. Ah, I didn't realise people tested installed packages! When developing,...

I would say that as long as the units are recognised by [UDUNITS](https://www.unidata.ucar.edu/software/udunits/) or perhaps [pint](https://pint.readthedocs.io) then it should be ok -- `eV` for temperature should be accepted for instance....

BOUT++ LGPL so that if you dynamically link against it your code doesn't have to also be LGPL, e.g. as an optional plug-in. I'd be happy with LGPL for xBOUT,...

I'd be happy with any variation on `x/y/z_ind`, `i/j/k`, `ix/iy/iz` or `jz/jy/jz` as long as it's documented up front :) I prefer those options as they're a little bit clearer...