Export blueprints for examples and load them from the viewer

[emilk]

Currently, the save feature of our Python API only saves the recording, but does not include the blueprint.

We need to also save the blueprint so that we can include the blueprint when users click the examples in the welcome screen of the Rerun Viewer.

There are multiple approaches we could take to support this, each with different trade-offs.
We don't fully know which tradeoffs makes sense for most users, so in the interest of easing into complexity I suggest we take the simplest approach first, and then work from there.

Suggestion: Bundling the blueprint in the recording .rrd

When a user uses rerun.save they are given the option to also include a blueprint into it (just like they are with spawn). If they do, the blueprint is also sent to the same .rrd file. This again mirrors how spawn works (if you include a blueprint argument, that is included in the message stream to the sink).

If we do this simple step, then we will get the example blueprints working right away.

This would also go for other shortcuts to hitting rerun.save, including rr.script_setup and _RERUN_TEST_FORCE_SAVE.

One downside is that it means you cannot easily load a recording without running the risk of it over-writing your current blueprint. I think this is a UI issue, and can be solved with better UI, if/when we discover this is a real problem for real users. For instance: in the GUI we show which recording come with a blueprint, and to either heed or ignore it.

Alternative: save two files

One alternative is to add a rerun.save_blueprint with its own path, and do the same for the CLI setup of script_setup and adding a _RERUN_TEST_FORCE_SAVE_BLUEPRINT. This will mean we would need to throw around two files (.rrd and .rbl) everywhere, including adding both to our upload scripts when building example, adding both to the example manifest, downloading both in the viewer when loading examples, etc. A lot more work for sure.

It will also be annoying for a certain number of users that now need to pick two paths when saving stuff using the rerun SDK, send two files to their colleague, add two url parameters to their web viewer, etc etc.

I think a much better approach is to add a rerun.save_blueprint that a user can optionally use if they prefer it.

Notes

The in-viewer commands are currently Save recording… and Save blueprint…. I don't propose we change that now. However, me should add some way of saving a single .rrd that includes the blueprint, e.g. as a checkbox when saving the recording ([x] Include blueprint).

We could invent a third file extension that means "this contains both a recording and a blueprint". However, I think this is just adding too much complexity to our product. I rather have very few file extensions and then good tools for working with them (e.g. rerun print foo.rrd should state how many recording and/or blueprints are in that file).

[jleibs]

Note that many of the UI improvements that would come out of #5298 also improve the "bundled" workflow.

[nikolausWest]

I see the merits of this approach practically but I'm worried about the added cost to user's mental models. You're probably correct that this is the best solution but we need to remember this when writing docs and tutorials to really make it clear what is happening and that there are different approaches you can take.

From my observation of users getting started with Rerun, the main piece of friction isn't workflow in the easy case, it's figuring out what Rerun is and how you're expected to use it.