Feature/push to quay.io

[SebastianSchildt]

Do for kuksa-client what eclipse-kuksa/kuksa-databroker#36 did for databroker

[SebastianSchildt]

@erikbosch or @wba2hi Any idea why the tests fail? "Wasn't me" (I hope)

[wba2hi]

@erikbosch or @wba2hi Any idea why the tests fail? "Wasn't me" (I hope)

Only thing I see is this here:
/home/runner/work/kuksa-python-sdk/kuksa-python-sdk/kuksa-client/kuksa/val/v1/val_pb2_grpc.py:21: RuntimeWarning: The grpc package installed is at version 1.63.0, but the generated code in kuksa/val/v1/val_pb2_grpc.py depends on grpcio>=1.64.1. Please upgrade your grpc module to grpcio>=1.64.1 or downgrade your generated code using grpcio-tools<=1.63.0. This warning will become an error in 1.65.0, scheduled for release on June 25, 2024.

So updating the grpcio and grpcio-tools libs most probably should fix the issue if no new breaking changes were introduced. However I don't understand where this hard dependency now comes from. We updated grpcio and grpcio-tools to 1.63.0 here #27 and everything was working fine, we didn't make any updates to requirements.txt / test-requirements.txt since then

[erikbosch]

Will take a look at it

[erikbosch]

My analysis in short:

• When generating the gRPC Python files the tooling does not consider requirements.txt, instead it goes only after what is specified in setup.cfg, and there we in general have quite flexible requirements on version ( grpcio-tools>=1.63.0).
• So requirements.txt only specifies what is needed for running the kuksa-client

erik@debian6:~/kuksa-python-sdk/kuksa-client$ pip install -v -r requirements.txt -e .
Using pip 24.0 from /home/erik/.local/lib/python3.10/site-packages/pip (python 3.10)
Defaulting to user installation because normal site-packages is not writeable
Obtaining file:///home/erik/kuksa-python-sdk/kuksa-client
  Running command pip subprocess to install build dependencies
  Collecting grpcio-tools>=1.63.0
    Using cached grpcio_tools-1.64.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.3 kB)
  Collecting setuptools>=42
    Using cached setuptools-70.0.0-py3-none-any.whl.metadata (5.9 kB)
  Collecting setuptools-git-versioning
    Using cached setuptools_git_versioning-2.0.0-py3-none-any.whl.metadata (5.8 kB)
  Collecting wheel
    Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
  Collecting protobuf<6.0dev,>=5.26.1 (from grpcio-tools>=1.63.0)
    Using cached protobuf-5.27.1-cp38-abi3-manylinux2014_x86_64.whl.metadata (592 bytes)
  Collecting grpcio>=1.64.1 (from grpcio-tools>=1.63.0)
    Using cached grpcio-1.64.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.3 kB)
  Collecting packaging (from setuptools-git-versioning)
    Using cached packaging-24.1-py3-none-any.whl.metadata (3.2 kB)
  Collecting toml>=0.10.2 (from setuptools-git-versioning)
    Using cached toml-0.10.2-py2.py3-none-any.whl.metadata (7.1 kB)

Some googling did not find a quick and beautiful solution to this. This should not be a problem for already released versions, only if you build and run from scratch so maybe we can live with the limitation. Created a PR at #31 to update dependencies

Alternatively we could have fixed dependencies in setup.cfg, but I am not sure if that is a better idea.

[SebastianSchildt]

Thanks for analysing this. Should be fixed now