do not force_ndarray_like

[burnpanck]

• Closes avoid setting force_ndarray_like = True #216
• Passes pre-commit run --all-files
• User visible changes (including notable bug fixes) are documented in whats-new.rst

[TomNicholas]

Thanks for opening this @burnpanck .

I notice in tests/test_accessors.py we also separately set force_ndarray_like=True

pint-xarray/pint_xarray/tests/test_accessors.py

Line 25 in a9bb22b

unit_registry = UnitRegistry(force_ndarray=True)

That seems odd in that it doesn't fully decouple the tests from the code, and also seems like it might be making this PR misleading by causing tests to pass in the CI that would not work in user code?

[burnpanck]

Didn't spot that one. However, the tests still pass on my machine. To me, this suggests that force_ndarray_like is really not needed for any of the core xarray/pint interop to work. The only case that has been offered is the automatic coercion of a scalar quantity into a zero-dimensional array in the construction of a DataArray. But I strongly suggest that we add a test for that if we even want to claim that this is an actual feature.

[keewis]

As I pointed out in #216 (comment), it is possible to use pint + xarray without pint-xarray, so most of the tests that do check compatibility live in xarray's test suite (for now, there's the desire to move those tests here once we have a replacement that still does extensive checks of the duck array compatibility).

After changing the unit registry of these tests to have force_ndarray_like=False 107 tests are failing, so clearly this is important for pint support in xarray.

[burnpanck]

it is possible to use pint + xarray without pint-xarray

I'll have to process that. I'm wondering why one should be using pint-xarray in the first place then. I'll try to have a go at reproducing those failing tests in xarray so I understand better.

[keewis]

pint-xarray is a glue / convenience package: while it is possible to use (most of) pint + xarray without pint-xarray, it is not very convenient to do so: creating quantities, converting between them, and serializing back to array + attribute would be very complex otherwise (however, this will change with #163, which will allow having units on indexed coordinates, something that currently is not possible).

[burnpanck]

I would like to pick this up again. In our company, we have internal libraries that depend on pint-pandas, and libraries that depend on pint-xarray. As mentioned elsewhere, those two are fundamentally incompatible because of pint-xarray forcing global changes into the environment. In the past, we worked around that by pushing a build from this branch to an internal registry and using that, but that is a deployment complication that I would like to avoid.

Because of our experience with that and the precedent of pint-pandas, I'm still not convinced that pint-xarray cannot be fixed/working around the issues in pint without force_ndarray_like=True. So, to pick this up, I should now prove that, by showing that all tests can be made to pass. I realise that with xarray-array-testing, the landscape for testing things may have changed in the meantime. @keewis could you give me short pointer on how pint + xarray tests are currently being run?

[keewis]

on how pint + xarray tests are currently being run?

xarray-array-testing does not cover everything yet, so you'd still have to run the tests in xarray/tests/test_units.py to see which parts of xarray will fail (once it does cover everything, though, the xarray(pint(**)) tests will be added and run in this repository)

[doronbehar]

Perhaps we can add a test as in this comment?

[doronbehar]

Isn't this comment should be modified as well?

[keewis]

for anyone interested in this, please check out the quantity API standardization efforts, which should allow for a cleaner separation between scalar quantities and array quantities.