-
Notifications
You must be signed in to change notification settings - Fork 259
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
spin doctor
prototype
#1435
spin doctor
prototype
#1435
Conversation
d68506c
to
2e838aa
Compare
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.
Couple questions but otherwise very excited about this, LGTM
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.
A number of nits and suggestions, most if not all of which can be deferred to future PRs; really good stuff and I really appreciated the clean structure of it.
src/commands/doctor.rs
Outdated
|
||
impl DoctorCommand { | ||
pub async fn run(self) -> Result<()> { | ||
eprintln!("{icon}The Spin Doctor is in.", icon = Emoji("📟 ", "")); |
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.
Well, this is another matter of taste... I really dislike peppering command output with emoticons, because the effect is often this kind of rainbow soup of mismatched shapes and colours where nothing stands out any more (and of course console icons tend not to line up with OS conventions), and so becomes visual clutter rather than guiding the eye to different stanzas and states. I think they can be super useful when used to support and structure the UI, though, so we can iterate on this for sure.
To be even nittier (and more pet peevish), this goes double for relatively detailed icons like the "checking" icon (stethoscope?) - there is quite a bit of detail below text size and my old eyes find that difficult. If we are having icons then let's choose ones that are relatively bold, simple shapes.
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.
I expected this to be controversial. 😉 😛 🐱
I'm not married to the emoji per se but I do think the UX benefits from some visual cues to break up the chunks of interaction.
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.
To throw my opinion in the ring: I quite like emoji because I do find that it helps guide my eye, but more than anything I would prefer color output. I find spin output generally very hard to read because it all comes out looking like a wall of text.
src/commands/doctor.rs
Outdated
#[clap(hide = true, about = "Run the Spin Doctor")] | ||
pub struct DoctorCommand { | ||
#[clap(short = 'f', long, default_value = "spin.toml")] | ||
file: PathBuf, |
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.
Future suggestion: a --dry-run
or --check
flag that prints the diagnoses without any interaction and returns distinctive exit codes for "no diagnoses", "non-critical only", and "critical, allowing it to be used as a linter?
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.
Ooh I really like this
|
||
use std::{fmt::Debug, fs, future::Future, path::PathBuf, pin::Pin, process::Command, sync::Arc}; | ||
|
||
use anyhow::{ensure, Context, Result}; |
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.
nit: I know we do this everywhere, but I really prefer not using Result
unqualified. Unqualified Result
should always be std::result::Result
. Everywhere else we should use it qualified (e.g., anyhow::Result
, io::Result
, etc.). You don't need to address that here though since this is far from the only place where this occurs.
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.
While I understand the rationale, I don't think it's necessary for anyhow::Result
because 1) it is ubiquitous across the codebase (for better or worse) and 2) its definition makes it compatible with std::result::Result
:
pub type Result<T, E = Error> = core::result::Result<T, E>;
src/commands/doctor.rs
Outdated
|
||
impl DoctorCommand { | ||
pub async fn run(self) -> Result<()> { | ||
eprintln!("{icon}The Spin Doctor is in.", icon = Emoji("📟 ", "")); |
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.
To throw my opinion in the ring: I quite like emoji because I do find that it helps guide my eye, but more than anything I would prefer color output. I find spin output generally very hard to read because it all comes out looking like a wall of text.
48e8d46
to
606ff81
Compare
Signed-off-by: Lann Martin <lann.martin@fermyon.com>
While "old version key" and "wrong value" are logically different issues, from a UX perspective it seems better to let the "more critical" "wrong value" issue take precedence. Signed-off-by: Lann Martin <lann.martin@fermyon.com>
This changes the way diagnoses are "registered" with a Checkup; rather than storing function pointers it now stores trait objects. Signed-off-by: Lann Martin <lann.martin@fermyon.com>
The former is a short description to be displayed as a choice while the latter is a longer e.g. diff of what the treatment will do. Signed-off-by: Lann Martin <lann.martin@fermyon.com>
Signed-off-by: Lann Martin <lann.martin@fermyon.com>
Signed-off-by: Lann Martin <lann.martin@fermyon.com>
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.
I suggest we land this as hidden in its current form. There may be niggles but I don't think there are any blockers, and there is other work (the perennial wasm32-wasi
install woe) which is dependent on this and would be nice to kick off.
The subcommand is currently hidden from e.g.
spin --help
.