Planning the next few releases of Starship

[matchai]

Hey contributors and @starship/astronauts! 👋

This discussion is going to be where we plan out the next few releases of Starship, as well as plan what we want to be our primary focus for the next little while.

What I have written out below is entirely open to being changed, and is only what I had in mind. I'd love to have people voice their opinions as to how we can improve this plan, so please share anything that comes to mind! 🙏

Tentative Roadmap

v0.45.0

• Release format strings

After a whole lot of time spent working on #1057, this release will finally get it out the door. We will finish merging the format strings PR and push fixes as v0.45.X, until it feels stable.

v1.0.0

• Address major performance bottlenecks
  • Replace git2-rs with calls to git directly
  • Implement timeouts for modules taking too long
  • PRs for new modules that have been in our backlog for months

This will mark the first stable release of Starship, with many of users' performance concerns addressed, and our core modules and functionality set in stone. This will give us the freedom to release breaking changes as major version updates.

v2.0.0

• Ground-up rewrite of Starship
  • Written as a library and a separate CLI for users
  • Written with more idiomatic Rust, in a way that can allow for future extensibility
  • More robust logging, error messaging, and caching
  • Async?
• Breaking changes to the fundamentals of how Starship works
  • Modules appear based on the contents of the project root, rather than the current directory
  • Works with various VCSs equally, no longer giving Git preferred treatment

This will mark a new major milestone for Starship, allowing us to rethink the fundamentals of how it works since the project has changed and grown in scope. This will implement more of the functionality that has been tested in starship-poc.

[bbigras]

I'm curious about async? Did anyone do a PoC? or do we know if other projects are more awesome because of it?

[matchai]

I would imagine that Async would help in performance when it comes to I/O operations like filesystem reads. The main thing stopping me from giving it a try in starship-poc has been that our concurrency is handled by Rayon. It would be nice if I/O-bound async operations could also be balanced by Rayon, much like concurrency has been.

It looks like Rayon futures have been in limbo for some time here: rayon-rs/rayon#679

Of course, this is all speculation on my part. I haven't taken the time to really read up on futures as much as I'd like. I'd be happy to be shown another way we could effectively make use of both concurrency and async in Starship.

[chipbuster]

Ultimately, I don't think Rust-async (futures + jazz) will help us out much here, because some operations simply take way too long. You can multiplex filesystem operations all you like, but if you're like me and you're in a Git repo where several GBs of file have changed and need to be hashed, it'll still be a long time between when starship fires and when the result is ready.

I've seen several proposals for prompt asynchronicity, i.e. for a way for the prompt to be displayed even though not all the information is ready. This is implemented in several zsh shell prompts (notably, p10k and pure), and apparently makes a noticeable difference when some modules are slow to respond.

The big problem with this is that once starship returns, it loses control of the shell. That is, we would need to go back and replace the information that's already been drawn, but the shell has already taken control back from starship. This means that any attempts at prompt-asynchronicity have to be adapted per-shell, which is frankly a lot more work than I'm ready to take on at the moment, given how many shells we support and how many other shells have been requested.

Fundamentally, I can only see a few ways around this:

• Wait for v2.0 (or whenever pressing issues become less pressing) and then commit to supporting async on all currently-supported shells. This would require a ton of work and commitment from several shell specialists (or someone biting the bullet and learning how to async in every shell). For some shell (e.g. bash, ion), it might require writing an entire framework for asynchronous prompt rendering.
• Create unofficial configs that allow prompt-asynchronicity and rely on the community to maintain them. This might require a larger degree of library-ization of starship than currently exists.
• Give up the idea of first-class support for all shells and break out a feature matrix, showing that e.g. async prompt with zsh on MacOS is supported, but ion on Linux is not. We could also implement this in a support-tier fashion like rustc does, with highest-tier being bash/zsh/fish on UNIX-likes, and lower tiers receiving less guarantee of things working.

While I don't particularly like any of these solutions, I feel like the third violates a lot of what the ideal of starship is to me: a prompt that's consistently supported with any shell on any platform (as long as said platform can compile Rust). I'll admit that I can still see a future where events force our hand and we're required to go this route (not necessarily for async support) but I'd like to avoid it if possible.

That being said, this is all hypothetical, since nobody's gone and created the necessary async adapters to show that this could work (as far as I know). If we wanted to do so, I think the easiest low-hanging fruit would be to use either zsh-async or fish-async-prompt to make the entire prompt async, then look into potentially doing it finer-grained.

[chipbuster]

do we know if other projects are more awesome because of it?

Yes, a lot of people report that async prompts feel more responsive. In recent Rust projects, gitui uses async-git and seems to have much better response times than the competition.

[matchai]

I think evolving Starship into being an async prompt is an eventual end-goal, and may be a worthy milestone of a big v3.0 release following the rewrite done in v2.0.
Any work we do to move toward getting Starship to support async rust will be a step in the direction being an async prompt 👍

[bbigras]

I've seen several proposals for prompt asynchronicity, i.e. for a way for the prompt to be displayed even though not all the information is ready. This is implemented in several zsh shell prompts (notably, p10k and pure), and apparently makes a noticeable difference when some modules are slow to respond.

Yeah by async I was talking about an async prompt.

I also like async/await code with Rust. Especially more now that the futures 0.1 vs futures 0.3 nightmare is mostly over.

I'll check gitui. Thanks.

[thePaulRichard]

I think that will be nice if has an option to show it at bottom of the terminal, like tmux and vim powerline.