[GH-ISSUE #579] Split out config more for users with read-only configurations #241

New issue

Open

opened 2026-02-28 14:47:59 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @colemickens on GitHub (Sep 16, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/579

Hi,

Some of us are running into issues because the same file is used to store credentials as is used to store the current device playback id.

In NixOS and/or when using Home-Manager, we can specify our system and application configurations declaratively in Nix. These config files are stored on a read-only system and symlinked into place.

From skimming the code, it looks like any time the device is changed from the UI, the entire config file is rewritten, and it's fatal if the file cannot be written.

Possible solutions:

ignore failures on writing that config file (it would be very expected behavior, to me, to have a "default" device_id in the config file that can be overriden at runtime, and failing to update the default could be non-fatal).
split the device_id into something else (user_config doesn't seem appropriate either for the same reasons)

Ref: https://discourse.nixos.org/t/spotify-tui-and-readonly-filesystem/9012

Edit: and a big thank you for spotify-tui. It was nice to remove another Electron app from my system config today.

Originally created by @colemickens on GitHub (Sep 16, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/579 Hi, Some of us are running into issues because the same file is used to store credentials as is used to store the current device playback id. In NixOS and/or when using Home-Manager, we can specify our system and application configurations declaratively in Nix. These config files are stored on a read-only system and symlinked into place. From skimming the code, it looks like any time the device is changed from the UI, the entire config file is rewritten, and it's fatal if the file cannot be written. Possible solutions: - ignore failures on writing that config file (it would be very expected behavior, to me, to have a "default" device_id in the config file that can be overriden at runtime, and failing to update the default could be non-fatal). - split the device_id into something else (user_config doesn't seem appropriate either for the same reasons) Ref: https://discourse.nixos.org/t/spotify-tui-and-readonly-filesystem/9012 Edit: and a big thank you for `spotify-tui`. It was nice to remove another Electron app from my system config today.

kerem commented

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

Author

Owner

@Rigellute commented on GitHub (Oct 2, 2020):

There are two pieces of data that need persisting that are not known until runtime - device id and the auth token cache.

Do you have an issue when the token is written to the filesystem too? (~/.config/spotiy-tui/.spotify_token_cache.json)

Or is the issue only with the device id?

Is there a nix friendly location for writing to runtime managed config to the filesystem?

@Rigellute commented on GitHub (Oct 2, 2020): There are two pieces of data that need persisting that are not known until runtime - device id and the auth token cache. Do you have an issue when the token is written to the filesystem too? (`~/.config/spotiy-tui/.spotify_token_cache.json`) Or is the issue only with the device id? Is there a nix friendly location for writing to runtime managed config to the filesystem?

kerem commented

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

Author

Owner

@Jake-Gillberg commented on GitHub (Oct 2, 2020):

Thanks for the response!

To my knowledge, ~/.config/spotify-tui/.spotify_token_cache.json isn't a problem, because this isn't a file that you would want to have initialized to any specific value anyways. (which isn't the case for client.yml where you would want to pre-configure the client_id and port and such). All configuration files managed in nix are supposed to be static and read-only.

Nix usually stores these sorts of things in a location like ~/.cache/spotify-tui/, but any location in home should be fine as long as files containing configuration that should be set before spotify-tui is run aren't written to.

@Jake-Gillberg commented on GitHub (Oct 2, 2020): Thanks for the response! To my knowledge, `~/.config/spotify-tui/.spotify_token_cache.json` isn't a problem, because this isn't a file that you would want to have initialized to any specific value anyways. (which isn't the case for `client.yml` where you would want to pre-configure the client_id and port and such). All configuration files managed in nix are supposed to be static and read-only. Nix usually stores these sorts of things in a location like `~/.cache/spotify-tui/`, but any location in home should be fine as long as files containing configuration that should be set before spotify-tui is run aren't written to.