[aeppling]

Summary

• Extract main.rs into lib.rs + dispatch.rs to expose RTK as a library crate for downstream bundling
• Add post-release repository_dispatch to notify downstream consumers of new tags

Test plan

• cargo fmt --all && cargo clippy --all-targets && cargo test — 1729 passed, 0 errors
• All 38 routing tests preserved and passing
• Binary behavior unchanged: rtk --version, rtk git status, rtk gain identical output
• Verified no missing modules, enums, match arms, or helper functions vs original main.rs
• Doctest fix: no_run → ignore for illustrative example exposed by lib crate

[KuSh]

Apart from some unrelated changes in vitest_cmd and tracking, LGTM!

[aeppling]

postponed by team

[reneleonhardt]

"Postponed" by team and "invalid" label @aeppling, what can be done to improve and merge this refactoring?

[HetCreep]

A side effect of this split that may be worth adding to the case for it: the crate currently has 24 rustdoc examples that can never run.

Provenance: AI-assisted source audit, human-directed, at v0.44.2 (700bdde). The command below was run.

$ cargo test --doc
error: no library targets found in package 'rtk'

There is no src/lib.rs and no [lib] in Cargo.toml; main.rs declares mod core; privately. So every ```rust block in the doc comments is dead weight — never compiled, never verified.

They have already drifted as a result. src/core/tracking.rs and src/core/utils.rs carry examples written against a public API path that does not exist:

/// use rtk::tracking::Tracker;
/// use rtk::utils::strip_ansi;

The real paths are core::tracking and core::utils. Those use lines would fail to compile the moment doctests could run.

There is also at least one example whose assertion contradicts the code it documents — tracking.rs:1301-1322 states tokens = ceil(chars / 4) with assert_eq!(estimate_tokens("abcd"), 1), while the implementation is (text.len() as f64 / 4.0).ceil() and str::len() counts bytes. (That one is already tracked in #3359 with a fix in #3360.) A working cargo test --doc would have caught it at the time it drifted.

So the split would turn 24 currently-inert examples into checked ones — and, based on the two above, would surface a handful of pre-existing inaccuracies on the first run. Worth expecting that as part of the change rather than a surprise.

No opinion on the bundling motivation itself; just adding a second reason that is independently verifiable.

[vpelikh]

Hi @aeppling — this is exactly what’s needed for embedding RTK as a library in a tool with its own in-process bash execution (rather than a shell hook or an external binary on PATH). I noticed it’s currently shelved with the invalid label / “postponed by team” after being approved by both maintainers.

Is the lib split still on the table? Would a rebase onto develop (or addressing what held it up) help get it landed? Happy to help rebase or to field questions on the downstream use case: in-process registry::rewrite_command plus core::runner::run_filtered/run_streamed for captured-output compression.

[aeppling]

Hey guys, @vpelikh @HetCreep @reneleonhardt

Thanks for interest, yes still on the table, I'll try moving forward with this asap

[aeppling]

I'll move forward with this on next week I think, this week RTK 1.0.0 is landing with new features so this need to wait a little bit :)