Conversation
|
I am now realizing that I have overlooked / misunderstood what I'll try to figure out the way to avoid such a breaking change. Any help would be welcome. |
|
I have local version that causes |
|
I have updated implementation to make Application polymorphic so that return value can be contained by it and there for avoid breaking API. However I am still not very happy with a result as API still clunky as #[wait]
#[command(scan <path>, "Scans directory and submits all findings to knowledge-server")]
async fn scan(path: String, _cli: Cli) -> Result<()> {
println!("Scanning resources {:?}", path);
scanner::activate().await
}
#[wait]
#[direct()]
#[option(-p, --port, "Port to be used by the knowledge-server (Default 8080)")]
async fn base(cli: Cli) -> Result<()> {
println!("Default action {:?}", cli);
Ok(())
}
#[wait]
#[entry]
async fn main() -> Result<()> {
let app = run!();
if let Some(out) = app.out {
out
} else {
serve(app)
// ^^^ expected struct `commander_core::Cli`, found struct `commander_core::Application`
}
}Is it can be seen it is not even possible to delegate to default command. I think adding
I think current API is tailored towards 2. I think it would make sense to tailor it for 1. instead while still allow 2. if desired. I have proposed something towards that end in #19 |
Fixes #10.
These changes enforce that all commands have same return type as main, without assuming it to be
().I have also changedrun()!so that main is able to return that type in case--helpor something that does not match program runs e.g.Unfortunately it also implies thatrun()!will return in case matching command is found, which can be confusing.Applicationhad being made polymorphicApplication<Out>andout: Option<Out>field can was added to hold return value of the matched command, in case no command was run it will beNone.OnlyAnother significant change had being removal ofmod _commander_rust_Inner. That is because return type of themain(#ret) may resolve to something else given the new module scope. For example following code without it will not work becauseResult<()>would resolve to defaultstd::result::Resultin new module scope instead ofstd::io::Resultwhich it should instead.