-
Notifications
You must be signed in to change notification settings - Fork 1.3k
ui: log footer support message to standard error #9034
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
Conversation
| q = colorize("Having any troubles?", "yellow") | ||
| link = colorize("https://dvc.org/support", "blue") | ||
| footer = f"\n{q} Hit us up at {link}, we are always happy to help!" | ||
| ui.error_write(footer) |
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.
Tbh I'd prefer getting rid of this completely.
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.
why?
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.
- It's noisy
- not all errors are critical or require support. Errors are part of the workflow for the most part. eg:
$ dvc import-url https://data.dvc.org/get-started/data.xml
ERROR: unexpected error - [Errno 17] File exists: 'data.xml'
Having any troubles? Hit us up at https://dvc.org/support, we are always happy to help!- we don't have a way to distinguish if those errors are internal error or just normal UX/workflow. Even more so with fsspec, since they raise
OSError. Even if we could, dvc's scope has increased so much that it's hard to keep this distinction. - unnecessary support link/message gets added to the output
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.
Thanks for the details @skshetry .
It makes sense, but feels like most of the reasons are not really about the message itself but the circumstances around it.
I believe it would still be useful if we could show it when it really should.
I would even try to extend it by automatically dumping the traceback or something and making it easy to share (since that's basically what we already ask when someone reports an error from the support channel).
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.
Maybe we could add a config to opt-out to begin 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.
yeah, but atm the reality is that it's not helpful. It's not clear to me if that link is helpful to the users.
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, but atm the reality is that it's not helpful. It's not clear to me if that link is helpful to the users.
IIn the current state, I am ok with dropping it
Codecov ReportBase: 93.07% // Head: 93.06% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #9034 +/- ##
==========================================
- Coverage 93.07% 93.06% -0.02%
==========================================
Files 456 456
Lines 36814 36761 -53
Branches 5335 5324 -11
==========================================
- Hits 34264 34210 -54
- Misses 2025 2026 +1
Partials 525 525
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Closes #8956.