Use standardized config directories for storing `config.yaml`

[Ricardo Subtil]

The current behavior of reading a config file from the current workdir presents a few problems, particularly on Linux:

• It doesn't allow launching the app from a different path. This makes it harder for scripting and/or autostart behavior, as it requires cding into the executable directory (#48)
• The executable directory might not be writable, making configuration changes difficult. This makes packaging this app for various distros difficult, as modifying any packaged files is generally not advised.
• Due to the above, this app is not suitable to be available on typical paths (e.g. /bin, /usr/bin)

While these problems are centered on Linux, I'd suggest following standard practices for config file placement between different OSes as a robust way to fix such issues. https://github.com/kirsle/configdir is a cross-platform library that can handle this, and I've patched my version of deej to use this and it works without any issue. I'd contribute these changes, but since you're not accepting PRs, the best I can is to notify you of this friction on adoption on more Linux distros 🙂

[Omri Harel]

Hi @rsubtil, thank you for writing and for the detailed info!

I'm happy to make a change to this in the next version - the points you brought up are completely valid (and the first one can cause confusion on Windows too because it's not intuitive for everyone that they're meant to create a shortcut that starts in the correct location and then place that into their autostart directory).

I would need to ensure this is done in a backwards-compatible way, as I don't want to ask users to move their existing configuration elsewhere. This is crucial to preserve as deej is distributed in a portable manner, without an installer. I don't want to expect users to put their config file in a separate location, which is what an installer would typically do for them (also keeping in mind that unlike apps with GUIs, users are expected to open and change the config file before their first-time run - although this is going to become less of an issue with the next version too, which will be able to keep running even when connection initially fails and then allow users to edit the config from the tray option to open it)

But to avoid rambling - I think the reasonable thing to do given the circumstances of deej would be defaulting to CWD, then falling back to the XDG config path. Installers/packagers would be able to place the config in that location, but most users would still place it alongside their executable. This doesn't fully solve autostart for those users, but there are ways to work around that (such as copying the config from CWD - if one exists - over to the XDG path whenever deej starts).

I also wanted to say thanks for your understanding with regards to me preferring to make these changes in my own pace. It's really nice to receive an informative and well-intending request to consider a change, without the (often pressuring) expectation to necessarily incorporate your own version of that change. I really appreciate that - thank you.

Will of course leave this issue open until this is released, and for any further discussion.

[TetsujinXLIV]

Hello is there any update on this? Looking at this same issue with Pop!_OS. Tried the cd ~/deej/ && ./deej-release but it can't find the config it still wants to run from home directory.