Installation using poetry

Hello!

Currently, we've been installing git dependencies using poetry (https://python-poetry.org/). This works fine for openeo-odc and for openeo-pg-parser, however, for openeo-processes, there are some issues.

When attempting to install with poetry add git+https://github.com/Open-EO/openeo-processes-python.git, an error is received:

The dependency name for dcio-example does not match the actual package's name: datacube

Looking at setup.cfg, it appears dcio-example is a git repo which contains a fork of odc-core.

Would it be possible to remove this dependency, or at least move it out of the xarray extras, to allow for easy installation using poetry?

Thanks!

[LukeWeidenwalker]

Hi @ojaace - thanks for raising this!

We seem to have forked odc-core to add a single custom commit (Add support for 3D OpenEO job results) a while ago, and this fork doesn't seem to be actively maintained. This is definitely something we should take a closer look at, maybe there's a different way of achieving this support for 3D jobs that doesn't require a fork.

As an immediate fix for your problem, I think it wouldn't hurt to stick these datacube related dependencies into their own extras in setup.cfg - @SerRichard, what do you think?

@ojaace Are you planning on using open-datacube in your setup at all or just trying to install the process implementations by themselves and handling data I/O somehow differently? I'm asking because we have a big refactor of how this repo is built and distributed coming up ~2 sprints down the line and it would be interesting to know how devs elsewhere intend to use this project!

Thanks for your reply, @LukeWeidenwalker !

Yes, we make use of the ODC stack as much as we can. This includes odc-explorer and odc-ows.

Our own implementation is not very mature yet, so I am not sure how we intend to continue. Personally, I'm curious about using odc-stac to skip having index data into a database (and point it directly to a stac endpoint instead). Regardless, I think we're pretty set on loading data using odc+dask in one way or another. This means we'll end up with xarray objects, so the repositories found here are quite helpful to us right now.

[soxofaan]

I guess this is related to #91, and not only limited to poetry

[LukeWeidenwalker]

Just a quick update on this: After some internal discussion we've decided to factor out the backend-specific IO processes (loading/saving results and collections) to their own dedicated repo. That will get rid of the dependency on the custom datacube fork (+ others) and should make this repo easier to install in the future.

[danielFlemstrom]

Would this mean that the problem is just moved to that repo (for us if we want to use the load/save results ) ?

[LukeWeidenwalker]

Just to update - this will be addressed with #177. If you have any additional thoughts on how the build process should look, feel free to chime in on that PR!

[LukeWeidenwalker]

Closed with #177, this project now uses poetry to build.