Dev install missing openeo-udf?

[m-mohr]

I'm trying to install the client for development purposes (want to try the _repl_html_ in Jupyter), but after executing pip install -e .[dev] I receive that openeo-udf is missing:

PS C:\Dev\openeo-python-client> pip install -e .[dev]
Obtaining file:///C:/Dev/openeo-python-client
Requirement already satisfied: requests in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (2.22.0)
Requirement already satisfied: requests_mock in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (1.5.0)
Requirement already satisfied: shapely>=1.6.4 in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (1.6.4)
Collecting numpy>=1.17.0
  Downloading numpy-1.19.2-cp36-cp36m-win_amd64.whl (12.9 MB)
     |████████████████████████████████| 12.9 MB 3.2 MB/s
Collecting deprecated
  Downloading Deprecated-1.2.10-py2.py3-none-any.whl (8.7 kB)
Requirement already satisfied: pandas>0.20.0 in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (0.23.0)
Requirement already satisfied: pytest>=4.5.0 in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (4.6.2)
Requirement already satisfied: mock in c:\programdata\anaconda3\lib\site-packages (from openeo==0.4.8a1) (2.0.0)
Collecting xarray==0.12.3
  Downloading xarray-0.12.3-py2.py3-none-any.whl (566 kB)
     |████████████████████████████████| 566 kB ...
Collecting h5netcdf
  Downloading h5netcdf-0.8.1-py2.py3-none-any.whl (18 kB)
ERROR: Could not find a version that satisfies the requirement openeo-udf>=1.0.0rc2 (from openeo==0.4.8a1) (from versions: none)
ERROR: No matching distribution found for openeo-udf>=1.0.0rc2 (from openeo==0.4.8a1)
PS C:\Dev\openeo-python-client>

[m-mohr]

Removing the missing dependency from setup.py helps for now...

[jdries]

yes, other workaround is to also clone openeo_udf and do pip install -e .
or not use [dev]
or install it from this wheel: https://artifactory.vgt.vito.be/webapp/#/artifacts/browse/tree/General/python-openeo/openeo_udf/1.0.0rc2/openeo_udf-1.0.0rc2-py2.py3-none-any.whl

It's on our list to do a proper release on pypi. But in fact we would like to find a proper way to depend on openeo-udf without dragging in the whole server implementation.

[soxofaan]

But in fact we would like to find a proper way to depend on openeo-udf without dragging in the whole server implementation.

+1 for me

reference: internal ticket EP-3578

Currently, openeo-python-client has an optional dependency on openeo-udf (through local imports in the client implementation). The openeo-python-client tests have a hard dependency (global imports).

The dependency on openeo-udf is however not ideal, as this drags in a lot of secondary dependencies that are overkill for general openeo-python-client usage.

possible solutions:

• move openeo-udf's DataCube (or at least a base class of it) to openeo-python-client
• make it possible to depend on a slimmed down version of openeo-udf
• ...?

[m-mohr]

I think openeo-udf should only contain the underlying specification of the protocol and base classes, while openeo-python-udf should be the actual python server implementation (like openeo-r-udf). openeo-python-udf can then inherit from openeo-udf, but I'm not sure how easy all that would be as I think Sören implemented things in a way that documentation is generated from code.

[soxofaan]

openeo-udf should only contain the underlying specification of the protocol and base classes, while openeo-python-udf should be the actual python server implementation

well, that does not really solve your original issue I think. The problem is that openeo-python-client currently depends on openeo-udf for very little but the dependency drags in a lot of secondary unnecessary stuff. My current idea to resolve this is to reverse the dependency so that the necessary base classes are are in the python client and openeo-udf depends on that.

Ideally, openeo-python-client should have as few (lesser widespread) dependencies as possible I think.

[m-mohr]

I had assumed that the base udf classes (without any server stuff) would not have many (non-dev) dependencies (if any)... Then it would solve the issue, I think.
The other way round also feels a bit strange. Why would a UDF server depend on the Python client?

[jdries]

Our backend also depends on the python client. We simply do it like that, because it's more annoying for the large group of Python client users to drag in server dependencies than the other way round. (Backend devs tend to know how to deal with dependencies, client users are researchers for whom all of this is very magical.)
Putting it in a separate repo is an option, but same argument: introduces opportunities for dependency issues, that client users will not know how to deal with. Also consider the documentation perspective: having it in the client will also result in consolidated docs.

[soxofaan]

just merged #190 which solves this issue
(will be in next release 0.7.0)