`Command not found: poe`, because `h5py` fails to install

[amotl]

On CI, the Install project workflow step reports that installing h5py fails. As a consequence, poe will not be available, because the installation of dependencies terminated.

I am wondering why the corresponding command [^1] did not croak appropriately? I would have expected that the Install project workflow step would fail correctly.

-- https://github.com/earthobservations/wetterdienst/actions/runs/3465808093/jobs/5789593334#step:5:139

[^1]: poetry install --no-interaction --extras=sql --extras=export --extras=restapi --extras=explorer --extras=interpolation

Originally posted by @amotl in https://github.com/earthobservations/wetterdienst/issues/785#issuecomment-1314562669

[amotl]

I can confirm it works like that. Maybe the CI setup will need a corresponding adjustment?

docker run --rm -it python:3.11-slim-bullseye bash
apt-get update && apt-get install --yes build-essential pkg-config libhdf5-dev
pip install wheel
pip install h5py
python

>>> import h5py
>>> h5py.__version__
'3.7.0'

[amotl]

Despite of a SolverProblemError [1], the workflow step Install project succeeds. There is something wrong, no?

[1] https://github.com/earthobservations/wetterdienst/actions/runs/3466760679/jobs/5790954548#step:6:18

[amotl]

Specifically: Is h5py actually part of our baseline requirements, or not? Do we need it only for running the test suite?

-- https://github.com/earthobservations/wetterdienst/pull/787#issuecomment-1314650940

The radar tests at tests\provider\dwd\radar\test_api_historic.py needs h5py, see [1]. How did it work on Windows up until now?

[1] https://github.com/earthobservations/wetterdienst/actions/runs/3466910653/jobs/5791255793#step:7:68

[amotl]

Looks like installing h5py worked well only a few days ago, even on Python 3.11/macOS, using Poetry 1.2.2, e.g. at [1].

[1] https://github.com/earthobservations/wetterdienst/actions/runs/3406246127/jobs/5664802933#step:5:130

[amotl]

I am wondering why the corresponding command did not croak appropriately? I would have expected that the Install project workflow step would fail correctly.

Similar thing why I think the setup does not behave well: DuckDB fails to install, but nothing indicates that the process croaked. Why is that?

-- https://github.com/earthobservations/wetterdienst/actions/runs/3467576650/jobs/5792575196#step:6:256

[amotl]

While working on improving the situation around this issue with #787, I am wondering why all of that is happening only now?

FAILED tests/provider/dwd/observation/test_io.py::test_filter_by_sql - TypeError: Already tz-aware, use tz_convert to convert.
FAILED tests/ui/test_restapi.py::test_dwd_stations_sql - TypeError: Already tz-aware, use tz_convert to convert.
FAILED tests/ui/test_restapi.py::test_dwd_values_sql_tabular - KeyError: 'data'
FAILED tests/ui/test_restapi.py::test_dwd_values_sql_tidy - KeyError: 'data'

-- https://github.com/earthobservations/wetterdienst/actions/runs/3467649674/jobs/5792717522#step:8:1152

[amotl]

^^ My fault, I've upgraded DuckDB too much. Only bumped a bit now, with 17576a638.

[amotl]

I am wondering why the corresponding command did not croak appropriately? I would have expected that the Install project workflow step would fail correctly.

Similar thing why I think the setup does not behave well: DuckDB fails to install, but nothing indicates that the process croaked. Why is that?

dbd97a83ca9 improves the .github/workflows/install.sh program. Now, it will croak when any of the project setup command fails.

[amotl]

787 will hopefully resolve this issue, and #788 will further modernize the project and CI configuration.