Analytics: register SDK language and data source

[emilk]

Closes most of #396

Contains a bug fix for what SDK the log events originate from (we would before always set Python SDK as the source).

Adds a new field data_source which can be any of:

• file (.rrd)
• sdk (likely show())
• ws_client (likely spawn())
• tcp_server (likely connect())

Adds a app_env field that be any of python_sdk, rust_sdk, rust_cli, web (the latter won't happen until we have analytics on web).

Also adds a python_version when applicable.

Example

Starting rerun rust binary with CLI, then connecting to it from Python SDK:

TODO

• Add analytics for if the viewer was started from Rust or Python
• Python version
• Ensure we send events when loading a file from the viewer
• Send data_source as part of the open_recording event
• Send an event when serve() is called (serving a web browser) separate PR

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I've added a line to CHANGELOG.md (if this is a big enough change to warrant it)

[nikolausWest]

I don't think we should go with the name new_recording since it is easy to confuse it with "created new recording" when we actually mean something like "viewer opened new recording". I'd prefer open_recording

[emilk]

Maybe we should leave the patch version off the python_version to make it easier to split the data?

[teh-cmc]

This is absolutely fantastic.

I think this gives us a nice opportunity to streamline how we keep track of python & rust versions across host and recordings too (in another PR), see my inline comment.

---

Checklist:

• rust viewer cli
• rust spawn
• rust viewer - python connect
• rust viewer - rust connect
• rust viewer - then manually open python rrd
• rust viewer - then manually open rust rrd
• rust viewer - python rrd straight from cli
• rust viewer - rust rrd straight from cli
• rust serve
  • not working, as expected
• python viewer cli
• python spawn
• python viewer - rust connect
• python viewer - python connect
• python viewer - then manually open rust rrd
• python viewer - then manually open python rrd
• python viewer - python rrd straight from cli
• python viewer - rust rrd straight from cli
• python serve
  • not working, as expected

[teh-cmc]

We can actually avoid this issue entirely: the python version that corresponds to the machine the user is running on (i.e. the machine that hosts the viewer) should never be included in events, it should only be part of the user profile (along with the rust version that's already there) i.e. update_metadata.

The viewer_started event then only keeps track of the app environment, while the open_recording event always keeps track of the python_version that corresponds to the machine doing the recording, never the host.
We can also put the rust version of the machine doing the recording in there, for consistency.

That way everything becomes consistent and relatively straightforward to reason about:

• The python & rust versions seen in user profiles (update_metadata) are those of the host machine (the one hosting the viewer).
• The python & rust versions seen in events correspond to the machine doing the recording.

I think this changes are trivial to add on top of everything you just did?
If we agree on that I'll just make another PR.

[emilk]

sounds good!