Tracking issue: binary assets for everyone and everything #3942
Labels
🧑💻 dev experience
developer experience (excluding CI)
💬 discussion
⛴ release
Related to shipping or publishing
Milestone
Context
We want our (pre-)releases to contain pre-compiled per-platform per-arch binary assets for all things Rerun:
rerun_c
),rerun_cpp
),rerun_sdk.zip
),These release assets are the most reliable and scalable way to distribute Rerun, no matter how complex the end user's build system situation happens to be: they integrate well with even the most complex workflows.
Additionally, a pre-built viewer makes
spawn()
in Rust & C++ possible, and allows us to not embed the full viewer in our python wheel if we don't want to.For
cargo
users, it also makes installing the Rerun Viewer viacargo binstall
possible.Our contributor workflow is currently built on top of our cloud storage (build.rerun.io): all binary artifacts are neatly shipped and versioned in there, and CI actions simply copy stuff in and out as needed.
This is quite nice, but we cannot expect end-users to dig through our internal build systems to get what they need: only contributors should ever have to deal with build.rerun.io URLs.
End users wanting to get their hands on our release assets should need to go no further than the well standardized path provided by Github, which neatly integrates with a million tools out there.
Proposal
cargo binstall
works.spawn()
in all languages using$PATH
approach.spawn()
for all examples in all languages.Pending questions
arrow-cpp
artifacts?Related issues
spawn
-like functionality to C++ and Rust #3757spawn
in favor of fork-exec + binary artifacts #2109rerun
binary release artifacts #2107rerun
binaries on popular package managers #2108The text was updated successfully, but these errors were encountered: