-
Notifications
You must be signed in to change notification settings - Fork 893
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
Bug 1800: only open terminfo once #1820
Conversation
7e1b133
to
cd5f6d4
Compare
I'm not sure why the tests are failing; they are passing for me :/. |
All the failures appear to be in |
I can confirm i see the same errors on my laptop so I'll try to diagnose later today. |
Looks like there're formatting codes present in the output even under test... I changed print_indented in clitools.rs to debug-print things and:
|
Thanks; that will be a bug in the isatty detection glue then I guess - as the tests are passing for me under vscode on windows. Will look in ~48 hours. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM. A few comments / tweaks, and then I think we could merge. I like the caching, I like the split out of the markdown stuff (particularly since we've had some discussion about moving to a different markdown crate in the future too)
I did a slightly more than minimal fix here, promoting the term::Terminal trait to be the contract that our markdown formatting is written to, making the auto-disabling of formatting on non-tty's and handling of non-colour terminals be clearly separated out. The handling of corrupt or missing terminfo configuration is also pushed down to the underlying terminal trait object rather than having a bypass in our higher level code; this makes the upper layers easier to reason about. There is a modest increase in size, as the full term::Terminal trait is now implemented for the translation layer; a decorator macro could probably be writtent to shrink that if needed. There is a remaining direct use of term in download_tracker that causes a second open of the terminfo database, which should also be fixed but it is constant in nature so a later pass can do it. I don't have any tests for this; doing a unit test would be uninteresting in this case - rust's types give use what we need at that level, and for the conceptual level 'nothing else in the system calls any term calls', unit tests are inappropriate. A good way to test this would be to have the functional tests instrumented and make assertions about the behaviour of those executions; then any future regressions (e.g. if switching to a different term library) would be detected.
What needs to happen to merge this? |
I'd be also interested in this, so I can really start working on #1818 without having merge conflicts in the end :/ |
I have a followup that will likely conflict with 1818 as well; - the reason download_tracker didn't use term2 was that term2 was in the cli package, but the download_tracker was in the root, and I presume we don't want the root depending on the CLI. |
(that branch is https://github.com/rbtcollins/rustup.rs/pull/new/tracker-term-use ) - I'll set up the PR once this merges. |
Sorry for the delay :D |
I did a slightly more than minimal fix here, promoting the
term::Terminal trait to be the contract that our markdown formatting
is written to, making the auto-disabling of formatting on non-tty's
and handling of non-colour terminals be clearly separated out.
The handling of corrupt or missing terminfo configuration is also
pushed down to the underlying terminal trait object rather than
having a bypass in our higher level code; this makes the upper layers
easier to reason about.
There is a modest increase in size, as the full term::Terminal trait
is now implemented for the translation layer; a decorator macro could
probably be writtent to shrink that if needed.
There is a remaining direct use of term in download_tracker that causes
a second open of the terminfo database, which should also be fixed but
it is constant in nature so a later pass can do it.
I don't have any tests for this; doing a unit test would be
uninteresting in this case - rust's types give use what we need at that
level, and for the conceptual level 'nothing else in the system calls
any term calls', unit tests are inappropriate. A good way to test this
would be to have the functional tests instrumented and make assertions
about the behaviour of those executions; then any future regressions
(e.g. if switching to a different term library) would be detected.