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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up FSLeyes version checking to be less verbose/confusing #3820
Merged
joshuacwnewton
merged 5 commits into
master
from
jn/3816-clean-up-fsleyes-dependency-check
Jul 8, 2022
Merged
Clean up FSLeyes version checking to be less verbose/confusing #3820
joshuacwnewton
merged 5 commits into
master
from
jn/3816-clean-up-fsleyes-dependency-check
Jul 8, 2022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is supposed to help convey to the user that if an error occurs while checking the FSLeyes version, then it's non-critical and won't affect the processing of SCT.
joshuacwnewton
force-pushed
the
jn/3816-clean-up-fsleyes-dependency-check
branch
from
June 27, 2022 19:10
dd3bc04
to
303f9f6
Compare
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more.
|
# NB: We put this section first because typically, it will error out, since FSLeyes isn't installed by default. # SCT devs want to have access to this information, but we don't want to scare our users into thinking that # there's a critical error. So, we put it up top to allow the installation to end on a nice "OK" note.
joshuacwnewton
commented
Jun 29, 2022
mguaypaq
approved these changes
Jul 8, 2022
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.
The output is as discussed in the SCT dev meeting, so LGTM. Thanks!
This was referenced Jul 12, 2022
mguaypaq
added
enhancement
category: improves performance/results of an existing feature
sct_check_dependencies
context:
labels
Jul 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
category: improves performance/results of an existing feature
sct_check_dependencies
context:
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
GitHub
PR contents
Description
This PR is meant to simplify the complex error code checking for FSLeyes. Rather than give detailed custom descriptions for every possible case, I've instead opted to echo the native error thrown by the shell.
Our goal with the custom error messages was to try to explain that FSLeyes wasn't present, but that we recommend the tool. That messaging was a bit muddled, though, given that multiple users have interpreted it as a critical error, when instead FSLeyes is optional. So, I was hoping that
OPTIONAL DEPENDENCIES
would be sufficient for conveying that FSLeyes is a nice to have, but not necessary.On Ubuntu, it looks like this:
But, perhaps this is still too intrusive? We could move "Optional Dependencies" to be before "Mandatory Dependencies" so that it isn't the first thing the user sees upon running
sct_check_dependencies
. That way, it's less likely to spook anyone into thinking that it might be an error, but will still be present for our own debugging (on the forum, etc.)Very open to discussion here on how it would be best to display this information... 馃
Linked issues
Fixes #3816.