search

eclipse-kuksa / kuksa-python-sdk

The Python SDK for Eclipse KUKSA
Apache License 2.0
3 stars 5 forks source link

Feature/push to quay.io #30

Closed SebastianSchildt closed 1 month ago

SebastianSchildt commented 1 month ago

Do for kuksa-client what https://github.com/eclipse-kuksa/kuksa-databroker/issues/36 did for databroker

SebastianSchildt commented 1 month ago

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

wba2hi commented 1 month ago

@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 https://github.com/eclipse-kuksa/kuksa-python-sdk/pull/27 and everything was working fine, we didn't make any updates to requirements.txt / test-requirements.txt since then

erikbosch commented 1 month ago

Will take a look at it

erikbosch commented 1 month ago

My analysis in short:

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 commented 1 month ago

Thanks for analysing this. Should be fixed now