Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(rust): Option to display toolchain names by qryxip #3414

Merged
merged 1 commit into from
May 4, 2022

Conversation

chipbuster
Copy link
Contributor

@chipbuster chipbuster commented Jan 11, 2022

Description

#559 was approved and then sat around waiting to be merged for over 18 months. I'm not sure what happened, but I want to extend my sincerest apologies to for @qryxip for the state of that PR. We clearly should have merged it before things got this bad.

I attempted to rebase this PR onto master several times, but to no avail: the PR comes from before the format strings change, so there were some incompatibilities with how it was structured.

This PR is an attempt to make things right: I have manually ported over the changes made by @qryxip in #559. Because they would have potentially constituted breaking changes (I'm not sure what we consider breaking right now), I have segmented off two code paths. The old codepath uses exactly the same code as is present on master. The new code path, based on #559, exposes two new format variables, named numver and toolchain. Enabling the behavior intended by #559 involve simply setting format = "via [$symbol($numver)\\(($toolchain)\\) ]($style)" in starship.toml.

Because so many codepaths potentially create performance issues, I have also created a module-level external command cache, known as RustToolingEnvironmentInfo. This uses OnceCell to cache the results of reading data from the environment. As a result, this version of the module is about twice as fast as master, though I have had not had time to do thorough benchmarks.

Motivation and Context

Closes #559
Closes #555

Screenshots (if appropriate):

I can replicate the behavior as shown in this comment on #559

image

TODOs

  • The tests are still broken due to the removal of certain override extractions that I have not had time to patch up.
  • Whitespace handling is not perfect and needs to be tuned.
  • Add styling options for $numver and $toolchain. (REJECTED)
  • Update documentation
  • Need to add tests to cover new codepaths.

Questions Moving Forward

I have these questions for the rest of Starship Command:

  1. Is this idea (in the abstract) still something we're still interested in merging? If no, ignore the remaining questions.
  2. Is the current path an acceptable way forward? This lets us incorporate the new features and keep the old ones with better performance, but the module has grown from ~580 lines of code to 800+, and I haven't added any new tests yet. If the code bloat is unacceptable, there may be other ways to merge this.
  3. How do we make sure @qryxip get the proper credit for this? I am willing to go as far as force-pushing this branch to their repository to revive feat(rust): Option to display toolchain names #559 if we feel it is an appropriate mechanism.

Copy link
Member

@davidkna davidkna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't look at this in depth yet, but I have a few comments

src/modules/rust.rs Outdated Show resolved Hide resolved
src/modules/rust.rs Outdated Show resolved Hide resolved
src/modules/rust.rs Outdated Show resolved Hide resolved
@segevfiner
Copy link
Contributor

@chipbuster chipbuster force-pushed the toolchain-name-merge branch 3 times, most recently from 3e37d23 to 11bc895 Compare January 25, 2022 21:55
@chipbuster
Copy link
Contributor Author

Rebased with squash to reduce the commit set (and strip out a few commits that were made in pure confusion)

Copy link
Member

@davidkna davidkna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beyond my comment, the changes look reasonable, but I might have missed something.

src/modules/rust.rs Outdated Show resolved Hide resolved
@chipbuster
Copy link
Contributor Author

Okay. I'll let this sit another few days and then try to do a self-review, since I think it's been long enough that I can come at it with a (relatively) clean slate.

Comment on lines 447 to 452
fn lookup_override(&self, cwd: &Path) -> Option<String> {
self.overrides
.iter()
.find(|(dir, _)| cwd.starts_with(dir))
.map(|(_, name)| name.to_owned())
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to integrate the changes from #3359 (longest match) and #3668 (proper prefix handling).

@Milo123459
Copy link
Contributor

Quick comment: nightly toolchains are suffixed with -nightly. It would be nice if this module doesn't display "nightly" twice (I presume it currently does).

@matchai
Copy link
Member

matchai commented Mar 10, 2022

Quick comment: nightly toolchains are suffixed with -nightly. It would be nice if this module doesn't display "nightly" twice (I presume it currently does).

If you take a look at the screenshot in the issue description, you can see the proposed output for nightly toolchains. "nightly" is only shown once.

@Milo123459
Copy link
Contributor

Ah, nice. This module looks really good by the way!

@davidkna
Copy link
Member

I think numver doesn't include the toolchain name for easier use with toolchain.
The default format string seems to be unchanged and should behave mostly the same.

@matchai
Copy link
Member

matchai commented Mar 10, 2022

Ah, I was of the impression that we were changing the default config for the Rust module. Probably something we should clear up. My thinking is that the updated format shouldn't constitute a breaking change because the same data is being presented in an easier-to-read format.

Imo, breaking the semantic meaning of the prompt should be breaking (e.g. changing a symbol), or changing what information can be presented.

Nevertheless, we do have breaking changes lined up for the next major bump. Perhaps we can update the config group this change as part of them, just to be safe?

How do you feel about changing the default format?

@matchai
Copy link
Member

matchai commented Apr 4, 2022

If we can agree on whether this should be released as a breaking or non-breaking change, I think it's ready to be merged.

I'd personally vote to make it non-breaking:
It's an enhancement of the default prompt without a semantic change. Custom format strings are unaffected.

@davidkna
Copy link
Member

davidkna commented Apr 4, 2022

It might be nice to handle this first before merging, but that could also be done later.
I would also consider this a non-breaking change.

@andytom
Copy link
Member

andytom commented Apr 4, 2022

I think this should be fine to treat as a non breaking change.

@chipbuster
Copy link
Contributor Author

chipbuster commented Apr 5, 2022

Okay. I'll need to pull in the changes as mentioned in this comment, and then this will probably be ready for final review.

EDIT: And also this one

@chipbuster chipbuster force-pushed the toolchain-name-merge branch from 523f493 to a9819d1 Compare May 3, 2022 03:01
@chipbuster chipbuster force-pushed the toolchain-name-merge branch 2 times, most recently from a244e4d to 1837486 Compare May 4, 2022 03:26
Copy link
Member

@davidkna davidkna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, I just noticed toolchain resolves to stable-aarch64-apple-darwin on my mac, which is too long and doesn't match the documentation.

@chipbuster
Copy link
Contributor Author

chipbuster commented May 4, 2022

Wait, I just noticed toolchain resolves to stable-aarch64-apple-darwin on my mac, which is too long and doesn't match the documentation.

I've figured out why this happens: the existing code, along with all tests, assumes that the default_host_triple value is set in the rustup settings file. This is not necessarily correct, and when it's not set, we currently just assume that there's no host target triple.

I've pulled in guess_host_triple (which was originally derived from rustup's code) to deal with this, though I don't know how to add a test for it since host triples are inherently part of the execution environment.

EDIT: I think long-term, the solution will be to move these methods into the RustupSettings struct, then use something like mockall to mock the values.

@chipbuster chipbuster force-pushed the toolchain-name-merge branch 2 times, most recently from 14dea80 to 5162e4d Compare May 4, 2022 20:01
@chipbuster chipbuster requested a review from davidkna May 4, 2022 20:03
let default_host_triple = rust_env_info
.get_rustup_settings(context)
.default_host_triple()
.or_else(|| guess_host_triple());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.or_else(|| guess_host_triple());
.or_else(guess_host_triple);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow, there's a lifetime error that happens when you do that. I don't have the motivation to debug lifetime issues on chained methods at the moment, which is why I have this weird set of assignments in the current commit, but that's definitely something to tackle later.

This is an actualization of PR starship#559 as originally envisioned by qryxip.

Adds the ability to display toolchain versions, either as extracted from
environment/settings files or by getting the host triple. As part of
this, several other major changes were needed:
- Many of the smaller functions within the code have been fused, moved,
  or dropped.
- The Rustup environmental info is now initialized lazily using
  OnceCells. This will hopefully lead to a performance increase.
- New configuration variables (`toolchain` and `numver`) have been added
  to allow finer-grained configuration.
- Override information is no longer read from `rustup` output. Instead,
  it is parsed from the same files that rustup would use to determine
  this info.

Co-authored-by: qryxip <qryxip@gmail.com>
@chipbuster chipbuster force-pushed the toolchain-name-merge branch from 5162e4d to 87802e4 Compare May 4, 2022 20:20
Copy link
Member

@davidkna davidkna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, I don't think you added commit credit for @qryxip yet. If you had trouble figuring out emails/the syntax, the GitHub desktop application works quite nicely for this.

@chipbuster
Copy link
Contributor Author

image

This is what I see from the commits page. Do I need to look somewhere else to see if credit counts on the commit?

@davidkna
Copy link
Member

davidkna commented May 4, 2022

This is what I see from the commits page. Do I need to look somewhere else to see if credit counts on the commit?

No it looks fine, I must have missed it.

@chipbuster chipbuster merged commit 393d62c into starship:master May 4, 2022
@chipbuster chipbuster deleted the toolchain-name-merge branch May 4, 2022 20:41
@chipbuster
Copy link
Contributor Author

@davidkna Thanks so much for putting time into reviewing this and catching my mistakes on multiple occasions!

Same to @matchai, @andytom, and @segevfiner for commenting, and of course, a huge thanks to @qryxip for proposing and writing most of the logic for this in the first place.

Now to deal with the aftermath, I have some things I'd like to fix in #3967. Work is never done :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Display toolchain name in the rust module
6 participants