Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Contrib:Make registry a global constant repository #1572
Contrib:Make registry a global constant repository #1572
Changes from 1 commit
ebfe116
f379daa
0967aee
72e8d43
741b362
f9e67d7
8714ae5
ac2c6bb
0416d9f
dca2ae5
537a9c0
8ed81ac
bf4ff8b
d0faf6d
d1d0c66
92dcfca
d7ff61c
25e99d3
95ed435
141736c
7d14b39
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not for this PR, but this whole file makes me sad. We shouldn't be monkey patching our own code to support extensions 😭
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This got me thinking: I understand that the integrations are not part of the core. Would it make sense to make the registry part of the core itself? It seems to be a bit "too modular" to have the extension support itself be modular, rather than something that's always there as part of the core.
TL;DR the main difference would be that we'd move this method directly inside the
Datadog
module.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can take a stab at that and see how it looks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking into it, I agree with this.
But I think this will modify too much to be able to fit nicely in this PR.
I documented this sentiment in code, so we know this is the direction we want for this part of our code in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: I agree with avoiding the bigger change, but on my second go around reviewing this I was thinking that we may be able to just inline the
Helper
module intodatadog.rb
, and thus start a bit on the correct path.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to refactor
Helper
, but it looked very ugly without moving the rest ofextensions.rb
with it 😐There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, thanks for making a try :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor:
Datadog.registry
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the message.
The reason to use
Datadog::Contrib::REGISTRY
internally in the tracer is that it's a direct access to the constant, and it's the only safe way to access the registry before the tracer initializes.Datadog.registry
is only available after the tracer has fully initialized.Today this makes no different because calls to
Datadog.registry
lazily trigger the initialization of the whole tracer, but after we eager initialize the tracer that won't be the case. Users will always receive the tracer initialized, but internal components might see it uninitialized during gem loading.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: This seems to be repeated so often that I wonder if we should have a nice helper for this -- something along the lines of
with_clean_configuration(:action_cable) { example.run }
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spoiler: 99% of these
reset_configuration!
will go away when the tracer is eager initialized (more so when the lifecyle object is correctly disposed and re-created on every run). So we'll soon remove these altogether instead :)