romainkomorndatadog
commented
5 months ago @pmourlanne , I'm wondering if there's something in the way your environment is set up that had you end up with a broken package. The PR that introduced the _build_git_packfiles_with_details function was the same that introduced its import, so I can't think of a reason why you would run into that import error.
I think I'll need your help to try and reproduce this, at least in terms of understanding how you're starting the application (eg: ddtrace-run or some other way) and what, if any, you're importing out of ddtrace. Which version of Python are you using?
With 3.11.0, using a simple virtual environment with ddtrace==2.4.0 installed, I'm able to do the import that's failing for you, eg:
% python -c "from ddtrace.ext.git import _build_git_packfiles_with_details; print(_build_git_packfiles_with_details.__module__)"
ddtrace.ext.git(pip freeze details)
``` attrs==23.2.0 bytecode==0.15.1 cattrs==23.2.3 ddsketch==2.0.4 ddtrace==2.4.0 Deprecated==1.2.14 envier==0.5.0 importlib-metadata==6.11.0 opentelemetry-api==1.22.0 protobuf==4.25.1 six==1.16.0 typing_extensions==4.9.0 wrapt==1.16.0 xmltodict==0.13.0 zipp==3.17.0 ```If anything, I would expect #7955 to be a more likely culprit (since it introduced a dependency on logging), which at least would map to the AttributeError: module 'our-project-name' has no attribute 'logging' error you're seeing in the end.
As far as why the imports happen, I lazily used a breakpoint() after ddtrace.ext.git's import statements , and just did an import ddtrace in a python interpreter, and the stack looks like:
(Pdb) w
...
-> from .settings import _config as config
-> self.loader.exec_module(module)
-> from .config import Config
-> self.loader.exec_module(module)
-> from ..internal import gitmetadata
...which points to https://github.com/DataDog/dd-trace-py/blob/v2.4.0/ddtrace/settings/config.py#L20 :
from ..internal import gitmetadataAs a side note, we are relying on git metadata in a lot of places (and I'd say it's growing) to enrich the data we submit in spans, so maybe we'd have something to gain by moving some of ddtrace.ext.git's functionality to a utils module that isn't always imported along with ddtrace.ext.git.
benjaminrigaud
Summary of problem
On start-up, Sentry picks up the following error:
ImportError: cannot import name '_build_git_packfiles_with_details' from 'ddtrace.ext.git'. We indeed don't see any traces in Datadog following this error.The final error is
AttributeError: module 'our-project-name' has no attribute 'logging'.This issue appeared once we upgraded to dd-trace-py 2.4.0. I suspect https://github.com/DataDog/dd-trace-py/pull/7532 to be the culprit. I also don't understand why internal imports about ci visibility are run in our live environments.
Which version of dd-trace-py are you using?
2.4.0
Which version of pip are you using?
pip 23.3.2
Which libraries and their versions are you using?
`pip freeze`
$ pip freeze amqp==5.1.1 analytics-python==1.2.9 argon2-cffi==23.1.0 argon2-cffi-bindings==21.2.0 asgiref==3.7.2 asttokens==2.2.1 attrs==23.1.0 awscli==1.29.85 backcall==0.2.0 billiard==3.6.4.0 boto3==1.28.80 botocore==1.31.85 bytecode==0.14.2 cached-property==1.5.2 cachetools==5.3.1 cattrs==23.1.2 celery==5.2.7 certifi==2023.7.22 cffi==1.15.1 charset-normalizer==3.2.0 click==8.1.3 click-didyoumean==0.3.0 click-plugins==1.1.1 click-repl==0.3.0 colorama==0.4.4 cryptography==41.0.7 datadog-api-client==1.12 ddsketch==2.0.4 ddtrace==2.4.0 decorator==5.1.1 defusedxml==0.7.1 Deprecated==1.2.14 Django==4.2.8 django-admin-autocomplete-filter==0.7.1 django-admin-inline-paginator==0.3.0 django-admin-rangefilter==0.10.0 django-adminfilters==2.0.4 django-autocomplete-light==3.9.4 django-better-choices==1.17 django-cors-headers==3.11.0 django-countries==7.1 django-db-views==0.1.5 django-environ==0.11.2 django-extensions==3.2.3 django-filter==22.1 django-jsonform==2.17.0 django-localflavor==3.1 django-otp==1.1.6 django-pgtrigger==4.6.0 django-rosetta==0.9.5 django-simple-history==3.0.0 django-storages==1.13.2 djangorestframework==3.14.0 djangorestframework-camel-case==1.3.0 docutils==0.16 envier==0.4.0 exceptiongroup==1.1.2 executing==1.2.0 gocardless-pro==1.49.0 google-auth==2.22.0 google-auth-oauthlib==1.0.0 greenlet==2.0.2 gspread==3.7.0 gunicorn==20.1.0 idna==3.4 importlib-metadata==6.8.0 ipython==8.12.0 isodate==0.6.1 jedi==0.18.2 Jinja2==3.1.2 jmespath==1.0.1 kombu==5.2.4 lxml==4.9.3 MarkupSafe==2.1.3 matplotlib-inline==0.1.6 oauthlib==3.2.2 opentelemetry-api==1.19.0 parso==0.8.3 parsy==2.0 pdfkit==1.0.0 pexpect==4.8.0 pickleshare==0.7.5 platformdirs==3.9.1 polib==1.2.0 prompt-toolkit==3.0.39 protobuf==4.23.4 psycopg2==2.9.9 ptyprocess==0.7.0 pure-eval==0.2.2 pyasn1==0.5.0 pyasn1-modules==0.3.0 pycparser==2.21 Pygments==2.15.1 PyJWT==2.6.0 pypng==0.20220715.0 python-dateutil==2.8.2 python-json-logger==2.0.7 python-Levenshtein==0.12.2 python-stdnum==1.18 pytz==2023.3 PyYAML==6.0.1 qrcode==7.4.2 requests==2.31.0 requests-file==1.5.1 requests-oauthlib==1.3.1 requests-toolbelt==1.0.0 rsa==4.7.2 s3transfer==0.7.0 sentry-sdk==1.14.0 setproctitle==1.3.3 shortuuid==0.5.0 six==1.16.0 slack-sdk==3.26.1 SQLAlchemy==1.4.49 sqlparse==0.4.4 stack-data==0.6.2 stripe==5.4.0 systemdunitparser==0.2 thefuzz==0.19.0 toml==0.10.2 traitlets==5.9.0 typing_extensions==4.7.1 urllib3==1.26.18 vine==5.0.0 wcwidth==0.2.6 wrapt==1.15.0 xmltodict==0.13.0 zeep==4.1.0 zipp==3.16.2How can we reproduce your problem?
This happens as soon as we start our application :shrug:
What is the result that you get?
As outlined above, an exception in Sentry, then no traces are sent to Datadog.
What is the result that you expected?
No exception, and traces sent to Datadog.