-
Notifications
You must be signed in to change notification settings - Fork 539
CLI now consistently forward URLs to native/web viewer when possible #10909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
/// Somewhere we can get Rerun logging data from. | ||
#[derive(Clone, Debug)] | ||
pub enum DataSource { | ||
pub enum LogDataSource { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's always been a log data source, it's just that the clarification until somewhat recently wasn't really necessary
not sure what's up with cargo-shear. The dependency it complains about is not there anymore 🤨 |
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/16972831822 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well great stuff ❤️ I definitely feels that the complexity of our model is increasingly becoming the bottleneck for further improving this code (maybe at the exception of these "mode of operation" I noted below, where dumb code shuffling might actual help).
struct UrlParamProcessingConfig { | ||
data_sources_from_http_urls: bool, | ||
data_sources_from_redap_datasets: bool, | ||
data_source_from_filepaths: bool, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this embodies "what doesn't right" by you 😅 Can't say I'm in love either, but at least this is very explicit at what its doing.
#[allow(dead_code)] // May be unused depending on feature flags. | ||
fn grpc_server_and_web_viewer() -> Self { | ||
// GRPC with web viewer can handle everything except files directly. | ||
Self { | ||
data_sources_from_http_urls: false, | ||
data_sources_from_redap_datasets: false, | ||
data_source_from_filepaths: true, | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This guy right here is the weird one. If we didn't support loading local file path from web viewer, we would be in a simpler world where we either eagerly (proxy) or lazily (native) convert everything to data sources, which could simplify stuff a bit more.
Do we really have reasons to support this use case?
(caveat: i may not understand correctly any of this and be completely wrong)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rerun --web-viewer some-local-file.rrd
is nice to support I think. Doesn't hurt too much I'd say
/// Makes the first recording store active that is found for a given data source if any. | ||
fn try_make_recording_from_source_active( | ||
&self, | ||
egui_ctx: &egui::Context, | ||
store_hub: &mut StoreHub, | ||
new_source: &SmartChannelSource, | ||
) { | ||
if let Some(entity_db) = store_hub.find_recording_store_by_source(new_source) { | ||
let store_id = entity_db.store_id().clone(); | ||
debug_assert!(store_id.is_recording()); // `find_recording_store_by_source` should have filtered for recordings rather than blueprints. | ||
self.make_store_active_and_highlight(store_hub, egui_ctx, &store_id); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some version of that facility might be nice to have for the new recording panel impl 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
happy to move around. was just a utility I've split after seeing the code for the third time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff isn't negative, argh!
Thanks for taking a stab at this. This is definitely an improvement. I ran some basic commands, but I believe we should merge it and crowd-source testing from the team 🙂.
Long-term, I wish we were more explicit, splitting different operating modes into their own commands. Or even better, reducing the number of operating modes...
💯 |
Felt the same. It really was supposed to be on this one 😅 |
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/16992022908 |
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/16994236785 |
@rerun-bot full-check |
Started a full build: https://github.com/rerun-io/rerun/actions/runs/16994529561 |
### Related * Follow-up to #10909 * related to https://linear.app/rerun/project/unblock-more-frequent-releases-fd370b484c42 ### What This broke pretty much all standard SDK->Viewer connections 😱
Related
What
This bottoms out in a long overdue refactor of our CLI entry point!
The key idea underpinning the CLI entry point refactor is that URLs should be processed differently depending on what we want to do with them: Whenever possible, we should not create a data source directly and instead forward them to the (web) viewer.
Still not amazing in structure, but imho way easier to follow now and probably fixes some subtle bugs as well.
Mostly manual testing, since this area unfortunately doesn't have a lot of unit testing:
pixi run rerun
then connect SDK to itpixi run rerun local.rrd
pixi run rerun "rerun://sandbox.redap.rerun.io:443"
pixi run rerun "rerun://sandbox.redap.rerun.io:443/dataset/1859BE6ABC6AF76718cec559c2c873c6?partition_id=IPRL_2fe9715d_2023_08_21_23h_35m_20s"
pixi run rerun https://app.rerun.io/version/0.24.0/examples/dna.rrd
pixi run rerun https://app.rerun.io/version/0.24.0/examples/dna.rrd
but there's already a viewer runningpixi run rerun --connect
to connect a viewer to itpixi run rerun-web
then connect SDK to it viaconnect_grpc
pixi run rerun-web "rerun://sandbox.redap.rerun.io:443"
pixi run rerun-web "rerun://sandbox.redap.rerun.io:443/dataset/1859BE6ABC6AF76718cec559c2c873c6?partition_id=IPRL_2fe9715d_2023_08_21_23h_35m_20s"
pixi run rerun-web https://app.rerun.io/version/0.24.0/examples/dna.rrd
pixi run rerun --serve-grpc
, send some data to it via sdk connect, then connect a web viewer to it--save
pixi run rerun --save new.rrd https://app.rerun.io/version/0.24.0/examples/dna.rrd
pixi run rerun --save new.rrd
and then connect an sdk to it viaconnect_grpc