Closed Bug 1646706 Opened 4 years ago Closed 4 years ago

Support debugging features through environment variables

Categories

(Data Platform and Tools :: Glean: SDK, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

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).

It was pointed out that this is more general than just Python -- it would be useful for all non-mobile platforms.

Summary: Python: Support debugging features through environment variables → Support debugging features through environment variables
Blocks: 1648007
Priority: P3 → P2
Whiteboard: [telemetry:glean-rs:m?]
Assignee: nobody → brizental
Priority: P2 → P1

Consider this situation:

  1. The user calls set_debug_view_tag;
  2. 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.

Flags: needinfo?(alessio.placitelli)

(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.
Flags: needinfo?(alessio.placitelli)

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.

(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.

Blocks: 1635253

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.

Attached file GitHub Pull Request
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: