Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library dependencies not working with python > 3.10 #2

Open
davetromp opened this issue Nov 23, 2022 · 1 comment
Open

Library dependencies not working with python > 3.10 #2

davetromp opened this issue Nov 23, 2022 · 1 comment

Comments

@davetromp
Copy link

The issue

I am working on developing ports. I am running python 3.10. I come across the following issue when starting a port server:

Traceback (most recent call last):
File "/home/dave/Projects/local-rds/RDS/layer1_adapters_and_ports/port_figshare/src/server.py", line 4, in
from init import app
File "/home/dave/Projects/local-rds/RDS/layer1_adapters_and_ports/port_figshare/src/init.py", line 38, in
app = bootstrap("PortFigshare", all=True)
File "/home/dave/Projects/local-rds/RDS/layer1_adapters_and_ports/port_figshare/src/init.py", line 24, in bootstrap
app = App(name, *args, **kwargs)
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/connexion_plus/Application.py", line 182, in init
from jaeger_client import Config as jConfig
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/jaeger_client/init.py", line 19, in
from .config import Config # noqa
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/jaeger_client/config.py", line 25, in
from .local_agent_net import LocalAgentSender
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/jaeger_client/local_agent_net.py", line 18, in
import tornado.httpclient
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/tornado/httpclient.py", line 50, in
from tornado import gen, httputil, stack_context
File "/home/dave/.local/share/virtualenvs/port_figshare-n1Gvbe7Y/lib/python3.10/site-packages/tornado/httputil.py", line 107, in
class HTTPHeaders(collections.MutableMapping):
AttributeError: module 'collections' has no attribute 'MutableMapping'

My analysis

Apparently MutableMapping has been depricated in the collections lib in python 3.10 or higher:
https://stackoverflow.com/questions/70943244/attributeerror-module-collections-has-no-attribute-mutablemapping

The tornado lib is using this. I am running version 5.1.1.

I tried upgrading it to the latest version 6.2, but this is not possible as another package is depending on tornado version <6.
This is the opentracing-instrumentation 3.3.1 lib.

And this package is a dependency for connexion-plus.

Workaround

A workaround I will be downgrading to python version < 3.10.

Hint for fix

The opentracing-instrumentation lib is deprecated. See:
uber-common/opentracing-python-instrumentation#118
The suggestion is to switch to OpenTelemetry?!

@davetromp davetromp changed the title Library dependancies not working with python > 3.10 Library dependencies not working with python > 3.10 Nov 23, 2022
@juriroemer
Copy link
Member

juriroemer commented Nov 25, 2022

Thanks for the thorough report! So, currently there is no actual Jaeger instance deployed in the Helm Charts to accept the traces (there was, but they were causing issues, so @Heiss removed them). This means, we have two options:

  1. remove all tracing (OpenTracing) for now, as it is deprecated and the traces aren't used at the moment anyway, basically removing the dead code that is causing the dependency issues.
  2. switch from OpenTracing to OpenTelemetry (which should hopefully not be to hard™️) and add a new backend (Grafana Tempo, Jaeger …) to collect traces, so we actually have a working tracing system.

The first option is rather easy and would not have an impact on Sciebo RDS in it's current form (without a tracing backend), but would remove a nice feature from connexion-plus. I think the second option makes a lot of sense on the long run, especially as we are getting to the point where we can provide Dev friendly Sciebo RDS environments in MiniKube.

Let's discuss this at our next meeting, but I agree that switching to OpenTelemetry (and therefore re-adding a tracing backend to the Sciebo RDS deployment, making this issue slightly more complex) seems the way to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants