Starship: Improvements to libraryisation of Starship

[Southclaws]

Feature Request

Is your feature request related to a problem? Please describe.

This is related to my recent PR #509 where a small change was made to make it possible to import Starship into another Rust program as an API so it can be embedded in shells that are written in Rust.

This was a great first step and made it possible to build a PoC PR for NuShell: https://github.com/nushell/nushell/pull/804 however I am interested in improving this more by making the interface into the prompt entirely structured so it doesn't rely on parsing Clap arguments.

Describe the solution you'd like

Remove the following from https://github.com/starship/starship/blob/master/src/context.rs#L15-L30

pub arguments: ArgMatches<'a>,

And pass parameters to modules using a more programmatic and structured approach which would decouple the prompt from the command-line interface so it's easier to embed into Rust shells.

This may be simple at first since there are only three modules that directly access arguments:

• character.rs
  
  
  
  • status_code and keymap which are just string values
    
    let exit_success = arguments.value_of("status_code").unwrap_or("0") == "0";

let keymap = arguments.value_of("keymap").unwrap_or("viins");
  
  
• cmd_duration.rs
  
  
  
  • cmd_duration which is converted into a duration value:
    
    rust let elapsed = arguments .value_of("cmd_duration") .unwrap_or("invalid_time") .parse::<u64>() .ok()?;
  
  
• jobs.rs
  
  
  
  • jobs which is parsed as an integer:
    
    rust let num_of_jobs = arguments .value_of("jobs") .unwrap_or("0") .trim() .parse::<i64>() .ok()?;
  
  

So in the interest of keeping things simple at first, it might be best to just replace arguments with a simple HashMap<String, String> to act as a super basic initial implementation of passing properties to modules.

Later on, I can imagine this getting cumbersome to write the parse code everywhere so it would probably be beneficial to have the modules declare what configuration flags they depend on and then generate flags from these. But, this would be quite a bit more work to the trait and implementation of plugins so probably best left until it's actually necessary.

Describe alternatives you've considered

I have considered constructing ArgMatches in source code but it's pretty ugly as it's a HashMap of MatchedArg which handles multiple instances of flags etc.

Essentially, it requires copious amounts of string literals which cannot be checked at compile-time and thus results in a higher risk of issues that can only be discovered at runtime.

[Southclaws]

Oh and of course I'm willing to work on this, just thought I'd put the idea forward before doing a PR 👍

[jonathandturner]

It's now working in Nushell! 🎉

This is using the minimal approach that @Southclaws started with, and we're interested in evolving this, too.