[GH-ISSUE #118] Implement logging #68

New issue

Open

opened 2026-02-28 14:46:46 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 14:46:46 +03:00

Owner

Originally created by @Valansch on GitHub (Oct 28, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/118

I found a few bugs, but i find it hard reporting them, since i don't get any log output whatsoever.

For example with #110 i'm pretty sure it's not a spotify-tui issue, but I have no idea what happend, since I didn't get any output so my only path to resolving this issue is to go straight up into developement and debug it myself. But at this time i'm not in the position to debug any Rust application.
For a hard crash (Exit code 1) i would expect at least an exception message in console or system log.

Since better logging => Better issues: Please help me help you.

It would also be nice to have a --verbose parameter.

Since i didn't find logging in the Roadmap, this issue exists.

Originally created by @Valansch on GitHub (Oct 28, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/118 I found a few bugs, but i find it hard reporting them, since i don't get any log output whatsoever. For example with #110 i'm pretty sure it's not a spotify-tui issue, but I have no idea what happend, since I didn't get any output so my only path to resolving this issue is to go straight up into developement and debug it myself. But at this time i'm not in the position to debug any Rust application. For a hard crash (Exit code 1) i would expect at least an exception message in console or system log. Since better logging => Better issues: Please help me help you. It would also be nice to have a `--verbose` parameter. Since i didn't find logging in the [Roadmap](https://github.com/Rigellute/spotify-tui#roadmap), this issue exists.

kerem commented

2026-02-28 14:46:47 +03:00

Author

Owner

@Rigellute commented on GitHub (Oct 28, 2019):

This PR https://github.com/Rigellute/spotify-tui/pull/111 recently adds better backtraces, but only in developer mode. Will look into enabling this via the flag.

@Rigellute commented on GitHub (Oct 28, 2019): This PR https://github.com/Rigellute/spotify-tui/pull/111 recently adds better backtraces, but only in developer mode. Will look into enabling this via the flag.

kerem commented

2026-02-28 14:46:47 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Nov 6, 2019):

I think this would be a good thing to add. Just to spark the conversation, I think we should address a few questions and come to some sort of consensus on what the feature should actually look like before diving in and choosing a logging backend crate.

My initial questions (in no particular order):

How should logging be configured (env vars, config file, ...)?
Should this be enabled via a feature flag, or always on?
Should this be a debug-only feature?
Do we need to log to various channels (e.g. API, app, ...), or is one aggregated log sufficient?

My thoughts:

I think configuration through config file makes sense here since we already have that mechanism implemented.
I think always on is fine, especially if it can be effectively turned off completely via the config. Rust's logging is pay-for-what-you-use, so I think having it compiled in always is not an issue.
See 2. However, I think by default, it should be turned to 11 for debug builds. Perhaps off (or error! only) by default in release builds
Depending on how noisy the logs become, it could be useful to separate into dedicated channels, but I don't know how idiomatic or well supported that is. I think an aggregate log is a fine fallback.

@sputnick1124 commented on GitHub (Nov 6, 2019): I think this would be a good thing to add. Just to spark the conversation, I think we should address a few questions and come to some sort of consensus on what the feature should actually look like before diving in and choosing a logging backend crate. My initial questions (in no particular order): 1. How should logging be configured (env vars, config file, ...)? 2. Should this be enabled via a feature flag, or always on? 3. Should this be a debug-only feature? 4. Do we need to log to various channels (e.g. API, app, ...), or is one aggregated log sufficient? My thoughts: 1. I think configuration through config file makes sense here since we already have that mechanism implemented. 2. I think always on is fine, especially if it can be effectively turned off completely via the config. Rust's logging is pay-for-what-you-use, so I think having it compiled in always is not an issue. 3. See 2. However, I think by default, it should be turned to 11 for debug builds. Perhaps off (or `error!` only) by default in release builds 4. Depending on how noisy the logs become, it could be useful to separate into dedicated channels, but I don't know how idiomatic or well supported that is. I think an aggregate log is a fine fallback.

kerem commented

2026-02-28 14:46:47 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 6, 2019):

Currently we have a panic hook that is enabled only for debug builds (introduced in #111), which at least prints the error to the console.

This uses the backtrace crate.

I think we could probably leave this on for release builds too now.

@Rigellute commented on GitHub (Nov 6, 2019): Currently we have a panic hook that is enabled only for debug builds (introduced in #111), which at least prints the error to the console. This uses the `backtrace` crate. I think we could probably leave this on for release builds too now.