dd-trace-py
dd-trace-py copied to clipboard
DataDog
Error compiling ddtrace/profiling/collector/stack.c with Python 3.11
Which version of dd-trace-py are you using?
1.2.2
Which version of pip are you using?
- Poetry 1.2.0b3
- Pip 22.1.2
Which version of the libraries are you using?
- gcc (Debian 10.2.1-6) 10.2.1 20210110
- g++ (Debian 10.2.1-6) 10.2.1 20210110
How can we reproduce your problem?
- Add ddtrace to
pyproject.tomlviapoetry add ddtrace - Build a Docker image with the following:
FROM python:3.11.0b4-slim-bullseye
RUN apt-get update && apt-get -y install libpq-dev git
RUN apt-get -y install build-essential
WORKDIR /workdir
RUN pip install poetry==1.2.0b3
# create virtual environment and activate it
RUN python -m venv /opt/venv
ENV VIRTUAL_ENV="/opt/venv" \
PATH="/opt/venv/bin:$PATH"
RUN poetry install
What is the result that you get?
Ddtrace-py is built from source, but fails. Full log here.
What is the result that you expected?
A native wheel would be supplied by Datadog.
But until this is available ...what am I missing in my Dockerfile?
Unsupported gcc version?
I looked at your CI configuration, and it's using gcc-10 and g++-10, and so is this Docker image, so I'm a bit confused 🤔
Hey @fredrikaverpil thank you for opening this issue.
We probably won't publish wheels for 3.11 until the official release in October.
However... we do need to introduce 3.11 into our test suite before then to fix any issues like this that we find. You are just one step ahead of us.
From the log you shared (thanks!), it looks like one of the C APIs the profiler is using changed.
#0 25.17 ddtrace/profiling/collector/stack.c:4167:73: error: ‘_PyErr_StackItem’ {aka ‘struct _err_stackitem’} has no member named ‘exc_traceback’
#0 25.17 4167 | PyTuple_SET_ITEM(__pyx_t_1, 1, ((PyObject *)__pyx_v_exc_info->exc_traceback));
Hey @brettlangdon 😊👋
it looks like one of the C APIs the profiler is using changed.
Ah!
We probably won't publish wheels for 3.11 until the official release in October.
I totally understand the reasoning behind this, but it would block/delay customers (such as myself) from starting to verify projects with Python 3.11, unless excluding ddtrace as a dependency during verification.
Having access to 3.11-compatible prereleases (or at least a 3.11 branch?) would be fantastic in case you would consider that.
Either way, would this issue be the best way to track this progress?
I totally understand the reasoning behind this, but it would block/delay customers (such as myself) from starting to verify projects with Python 3.11, unless excluding ddtrace as a dependency during verification.
👍🏻 good point, for now I am thinking of this more like a bug fix so we can ensure we are publishing a version of ddtrace which can be built from source for 3.11, but not publishing a wheel just yet.
Having access to 3.11-compatible prereleases (or at least a 3.11 branch?) would be fantastic in case you would consider that.
Makes sense, something for us to discuss! I don't think we've had this request in the past for 3.9/3.10/etc so new for us to figure out.
Either way, would this issue be the best way to track this progress?
Yes, for now let's use this issue to track. Maybe if we fix the specific C API usage we can close this, but then open up a follow-up request for publishing a 3.11 wheel. Does that make sense to you? (That I am thinking of this as a bug fix issue for the C API usage, instead of feature request for adding 3.11 wheel?)
Absolutely, we can use this issue as you proposed 👍 Feel free to rename the PR title if you wish!
Digging a bit further, I was able to reproduce easily. It seems the issue is actually from Cython. The code that fails to execute is generated from Cython.
I also tried with latest cython==3.0.0a10, but that just produced other errors...
it doesn't seem like the fix is going to be backported to 0.29.x, so we'd need to ensure our library works with Cython>=3.0.0 for 3.11 it seems. (this might take us a bit, but glad we are noticing this issue now)
No problem, glad I could be of help here 😅 I simply think the earlier we catch these things, the easier we can make this transition (to Python 3.11) eventually, as we can plan the required work along the way. 😇
@fredrikaverpil we are going to track overall progress to supporting Python 3.11 in #4149