issues

What happened:

In a Python environment with xarray 0.18.0 and python-netcdf4 installed, I called xarray.open_dataset("nonexistent"). (The file "nonexistent" does not exist.) xarray threw a ValueError: cannot guess the engine, try passing one explicitly.

What you expected to happen:

I expected a FileNotFoundError error to be thrown, as in xarray 0.17.0.

Minimal Complete Verifiable Example:

python import xarray as xr xr.open_dataset("nonexistent")

Anything else we need to know?:

This is presumably related to Issue #5295, but is not fixed by PR #5296: ValueError is also thrown with the currently latest commit in master (9165c266).

This change in behaviour produced a hard-to-diagnose bug deep in xcube, where we were catching the FileNotFound exception to deal gracefully with a missing file, but the new ValueError was of course not caught -- and the error message did not make the cause obvious. Catching ValueError is a workaround, but not a great solution since it may also be thrown for files which do exist but don't have a recognizable data format. I suspect that other codebases may be similarly affected.

xarray 0.17.0 was capable of throwing a ValueError for a non-existent file, but only in the (rare?) case that neither netCDF4-python nor scipy was installed.

Environment:

What happened:

I tried to use xarray to append a Dataset to a Zarr containing a |S1 (char string) datatype, and received this error:

ValueError: Invalid dtype for data variable: <xarray.DataArray 'x' ()> array(b'', dtype='|S1') dtype must be a subtype of number, datetime, bool, a fixed sized string, a fixed size unicode string or an object

What you expected to happen:

I expected the Dataset to be appended to the Zarr.

Minimal Complete Verifiable Example:

Note: this is not quite "minimal", since it also performs the append using the Zarr library directly and using a |U1 (Unicode) datatype in order to demonstrate that these variations work.

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

def test_append(data_type, zarr_path): print(f"Creating {data_type} Zarr...") ds = xr.Dataset({"x": np.array("", dtype=data_type)}) ds.to_zarr(zarr_path, mode="w")

print(f"Appending to {data_type} Zarr with Zarr library...")
zarr_to_append = zarr.open(zarr_path, mode="a")
zarr_to_append.x.append(np.array("", dtype=data_type))

print(f"Appending to {data_type} Zarr with xarray...")
ds_to_append = xr.Dataset({"x": np.array("", dtype=data_type)})
ds_to_append.to_zarr(zarr_path, mode="a")

test_append("|U1", "test-u.zarr") test_append("|S1", "test-s.zarr")

```

Anything else we need to know?:

I came across this problem when converting some NetCDFs from this dataset to a Zarr, appending them along the time axis. The latest data format vesion (1.4) includes a dimensionless variable crs with type char, which xarray reads as an |S1, causing the error described above when I attempt to append. Replacing crs with a |U1-typed variable works around the problem, but is undesirable since we need to reproduce the NetCDFs as closely as possible. The example above shows that the Zarr format and library themselves don't seem to have a problem with appending byte string variables.

The obvious fix would be to loosen the type check in xarray.backends.api._validate_datatypes_for_zarr_append:

python if ( not np.issubdtype(var.dtype, np.number) and not np.issubdtype(var.dtype, np.datetime64) and not np.issubdtype(var.dtype, np.bool_) and not coding.strings.is_unicode_dtype(var.dtype) and not coding.strings.is_bytes_dtype(var.dtype) # <- this line added to avoid "Invalid dtype" error and not var.dtype == object ):

This change makes the example above work, but I don't know if it would result in any unintended side-effects.

Environment: