Rename the protocol re-export to name its vendor #21

New Issue

Closed

opened 2026-08-03 13:43:09 +00:00 by day01 · 0 comments

day01 commented

2026-08-03 13:43:09 +00:00

Owner

src/lib.rs:8 re-exports one adapter under a vendor-neutral name:

pub use syncode_runner_control_gitea::protocol;

Every other re-export in that file names what it is — engine, source_git,
github_actions. This one promises neutrality the module does not have: it is
the Gitea Connect family, and src/cli/control.rs:9-17 confirms the scope by
mapping SynCode, Gitea and Forgejo onto GiteaFamily while rejecting GitHub and
GitLab explicitly.

The cost lands when a second control-plane adapter arrives. crate::protocol
cannot then mean both, and everything importing crate::protocol::GiteaFamily
(cli/control.rs, cli/daemon.rs, cli/register.rs) has to move anyway. Doing
it now is a rename; doing it later is a rename plus a migration of whatever grew
on top.

Suggested: pub use syncode_runner_control_gitea::protocol as gitea_protocol;
or expose it under control_gitea, matching how the crate is named.

`src/lib.rs:8` re-exports one adapter under a vendor-neutral name: pub use syncode_runner_control_gitea::protocol; Every other re-export in that file names what it is — `engine`, `source_git`, `github_actions`. This one promises neutrality the module does not have: it is the Gitea Connect family, and `src/cli/control.rs:9-17` confirms the scope by mapping SynCode, Gitea and Forgejo onto `GiteaFamily` while rejecting GitHub and GitLab explicitly. The cost lands when a second control-plane adapter arrives. `crate::protocol` cannot then mean both, and everything importing `crate::protocol::GiteaFamily` (`cli/control.rs`, `cli/daemon.rs`, `cli/register.rs`) has to move anyway. Doing it now is a rename; doing it later is a rename plus a migration of whatever grew on top. Suggested: `pub use syncode_runner_control_gitea::protocol as gitea_protocol;` or expose it under `control_gitea`, matching how the crate is named.