Hi there! New ncompare user here. I'm finding it quite useful so far. Many thanks to the developers for providing a great project. "Bug" isn't the best label here, but I wouldn't consider this an enhancement or feature request.
This issue is quite easy to fix, but its output is a bit annoying, especially when comparing lots of files like I am currently doing. Plus, it looks like this change will need to be made anyway. As far as I can tell, there are no functional issues related to this warning (yet).
Expected Behavior
I expect no warnings to be issued.
Actual Behavior
A FutureWarning is displayed related to the attribute dims vs sizes of an xarray dataset. It is raised every time ncompare is used. This does not appear to be related to usage of ncompare, rather, a hardcoded assumption related to an xarray object attribute in ncompare.
E.g.:
FutureWarning: The return type of `Dataset.dims` will be changed to return a set of dimension names in future, in order to be more consistent with `DataArray.dims`.
To access a mapping from dimension names to lengths, please use `Dataset.sizes`.
I have a fork with this change implemented that I am planning on submitting a PR with.
This change looks like it was introduced in xarray version v2023.12.0 (2023 Dec 08) so I would recommend changing related requirements to avoid backward compatibility issues.
Hi there! New
ncompare
user here. I'm finding it quite useful so far. Many thanks to the developers for providing a great project. "Bug" isn't the best label here, but I wouldn't consider this an enhancement or feature request.This issue is quite easy to fix, but its output is a bit annoying, especially when comparing lots of files like I am currently doing. Plus, it looks like this change will need to be made anyway. As far as I can tell, there are no functional issues related to this warning (yet).
Expected Behavior
I expect no warnings to be issued.
Actual Behavior
A
FutureWarning
is displayed related to the attributedims
vssizes
of anxarray
dataset. It is raised every timencompare
is used. This does not appear to be related to usage ofncompare
, rather, a hardcoded assumption related to anxarray
object attribute inncompare
. E.g.:Steps to Reproduce the Problem
ncompare
withpip
following: https://github.com/nannau/ncompare/tree/main?tab=readme-ov-file#option-b-using-pipncompare
from a Pythonsubprocess.call
with:Proposed solution
In this line of core.py we simply adopt the suggested change to be:
I have a fork with this change implemented that I am planning on submitting a PR with.
This change looks like it was introduced in xarray version
v2023.12.0 (2023 Dec 08)
so I would recommend changing related requirements to avoid backward compatibility issues.Specifications
2024.6.0