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
Add exclude lists for Django #670
Add exclude lists for Django #670
Changes from all commits
bb51246
6d89ba8
6078859
fc90ce3
656ba6b
b969c00
983899d
a13a611
0c6aff3
6b2b150
5dbd8c7
f105b45
5a67155
18f1c69
f6d0bb8
aec932e
d7bd164
4ea01b3
80d92bc
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.
I don't believe this will work as intended, or at least not consistently.
If the instrumentation is imported before configuration is set, then these values will be None, and as a result will not exclude any paths nor hosts. This is uncommon for environment variables where things are set before the process starts, but if we start including ways to configure the Configuration object (e.g. set once), this will result in these global variables resolving before anyone can set the configuration.
Here's a short example:
I think a safer approach would be lazy evaluation: have a getter than populates the value when it's called for the first time. Generally you can feel confident it won't be invoked until the first time it has to match the route, or after instrumentation.
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'm not sure I understand the use case. Configurations aren't able to be set, they are populated in the first instance that they are used by reading from the environment variables. If the instrumentation is imported, Configuration will just be set the moment that it is called.
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.
Currently, there is no way to set Configuration pro grammatically, although we might allow this in the future (set it once, and then it becomes immutable). A lazy load getter seems to makes sense as well in this case. I believe we should have this in a separate PR, since that is more about changing the API of Configuration.
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.
@ocelotl might have to weigh in, but I worry not doing this change now will result in a bug later on. I'll at least file an issue here.