Support debugging features through environment variables
Categories
(Data Platform and Tools :: Glean: SDK, defect, P1)
Tracking
(Not tracked)
People
(Reporter: mdroettboom, Assigned: brizental)
References
Details
Attachments
(2 files)
Using the debugging features with the Python bindings currently requires changing the user code to turn it on.
To make it more like the other platforms where you can use the debugging features on an "unmodified binary" (even if there's no binary), we could support using environment variables.
This would work for tagging and logging pings, but still wouldn't address the "send a ping now" use case (without having something listening on a network port or something which feels like something we wouldn't want to do).
Reporter | ||
Comment 1•4 years ago
|
||
It was pointed out that this is more general than just Python -- it would be useful for all non-mobile platforms.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
Consider this situation:
- The user calls
set_debug_view_tag
; - Then the user defines a new DEBUG_VIEW_TAG env var at runtime;
What is the expected behaviour here? Does the env var override the value set using the function? Should it actually replace what was set using the function or should it just temporarily replace and when the env var is unset we go back to using what was set with the function?
I personally think that in this situation it should only temporarily replace the value set with the function. I think it would be confusing if we were allowed to permanently override something using an env var.
Comment 3•4 years ago
|
||
(In reply to Beatriz Rizental from comment #2)
I personally think that in this situation it should only temporarily replace the value set with the function. I think it would be confusing if we were allowed to permanently override something using an env var.
I believe we should not overthink this and provide "too much magic" around it. We should keep in line with the expectations. If you think of this, what are the cases in which a user would both call the API and set the env variable?
- That's not possible on Android
- that's maybe possible on iOS, but unlikely to happen
- It won't be possible in Python, C# and FOG, since we'll remove the pingTag from the configuration.
Assignee | ||
Comment 4•4 years ago
|
||
Ok, but I still need to define this behaviour in order to implement it. At least on the way I am thinking of doing it.
So, what I am planning on doing, is changing this function where we get the value of the debug view tag, to check the environment before returning. If we have a tag set on the env we return the env value.
My question is: if I find the value in the environment, should I use it to override the debug_view_tag
on the Glean object? I don't think so, but I would like your input.
Comment 5•4 years ago
|
||
(In reply to Beatriz Rizental from comment #4)
My question is: if I find the value in the environment, should I use it to override the
debug_view_tag
on the Glean object? I don't think so, but I would like your input.
I believe it's fine to not override. If there's both an environment variable and a tag already set, log an error explaining what's going on, then use what was already set.
Comment 6•4 years ago
|
||
From FOG's POV I would like for a call to the API to override any present tag, whether the tag was set by the env or whether it was set by an earlier call to the API. This will, I think, be easier to communicate to FOG's users.
Assignee | ||
Comment 7•4 years ago
|
||
Comment 8•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Description
•