-
Notifications
You must be signed in to change notification settings - Fork 44
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
Use GIT_EDITOR for editing and approving with cargo vet certify #180
Conversation
This is an alternative approach to the `vet certify` UX which uses the GIT_EDITOR in order to prompt and ask the user to input notes, and accept a statement while also showing the criteria descriptions. In order to function more reliably on Windows, this code attempts to locate the git-for-windows install on the user's machine, and invokes the user's GIT_EDITOR through the git-for-windows' shell environment. This does not attempt to replace the interactive prompt for selecting which criteria to certify for. Fixes mozilla#165
Example text file for `cargo vet certify indexmap 1.8.1` in the test project:
|
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.
this all looks great!
src/editor.rs
Outdated
} | ||
|
||
// Trim off excess whitespace. | ||
Ok(result.trim().to_owned()) |
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 love this code because you trim as much as i do and it is such a relief
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 trim perhaps a bit more often than I should, but it seems to work here :p
assert!( | ||
!line.starts_with('#'), | ||
"Non-comment lines cannot start with a '#' comment character" | ||
); |
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.
Hmm this is an interesting failure mode. I was initially worried this would create roundtripping issues but we never feed existing notes from a toml back into the editor, so the only weird case would be someone passing notes in on the CLI with an explicit # line and they'll get a very quick error so seems fine.
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.
Yeah, I didn't love this as a failure case either. In git there's support for trying a sequence of comment characters and only falling over if all are used at the same time (https:/git/git/blob/9c897eef06347cc5a3eb07c3ae409970ab1052c8/builtin/commit.c#L669-L697), which I could add but it would require some changes to buffer the file in memory and only write it out with comments once it's been fully written.
The only place where this can come up right now though is if you pass a note on the command line which starts with a #
character on some line, as we write the note from the command line out in the file for editing.
src/editor.rs
Outdated
let file = BufReader::new(File::open(&path)?); | ||
for line in file.lines() { | ||
let line = line?; | ||
if line.starts_with('#') { |
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.
confirming: a line that starts with a space and then a #
is indeed not supposed to be treated as a comment? (both this code and add_comments seem to implicitly have this rule.
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.
That said this is kind of weird because if you have leading space on a line we will trim it away afterwards, so that leading space being significant is strange...
I suppose relatedly, do we want someone to be able to have any kind of indentation in their notes? Because this code will absolutely just eat that indentation.
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 think this code will only eat indentation at the start or end of the notes. IIRC I don't trim individual lines at all, so you can have leading whitespace for lines in the middle of your note.
The logic for comments is roughly copied from git's commitmessage, where IIRC only comment characters at the very start of the line are considered: https:/git/git/blob/74cc1aa55f30ed76424a0e7226ab519aa6265061/strbuf.c#L1135. I don't do all of the other fancy line cleanup stuff like removing trailing whitespace or collapsing extra newlines though :-)
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.
You immediately trim the line just below: result.push_str(line.trim());
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.
Oops, you're right. My bad
const LINE_ENDING: &str = "\r\n"; | ||
|
||
#[cfg(not(windows))] | ||
const LINE_ENDING: &str = "\n"; |
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.
NB Git does have some settings related to line endings and they are very annoying (this is fine for now though, especially since they're purely transient afaict) rust-lang/cargo#8523
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.
Yes, I agree that git's work around newlines is very annoying. This was basically just added as a defensive measure for when opening the editor on Windows, as the windows newline has no risk of being preserved, and everything's normalized immediately after. If I didn't do this, I believe that the notepad fallback on older windows systems would break, because notepad didn't support unix line endings for the longest time.
// NOTE: This is probably not as reliably available as `vi`, but is easier to | ||
// quit from for users who aren't familiar with vi. | ||
#[cfg(not(windows))] | ||
const FALLBACK_EDITOR: &str = "nano"; |
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.
god bless
This is an alternative approach to the
vet certify
UX which uses the GIT_EDITOR in order to prompt and ask the user to input notes, and accept a statement while also showing the criteria descriptions.In order to function more reliably on Windows, this code attempts to locate the git-for-windows install on the user's machine, and invokes the user's GIT_EDITOR through the git-for-windows' shell environment.
This does not attempt to replace the interactive prompt for selecting which criteria to certify for.
Fixes #165