Use XDG config spec #55

New Issue

ben · 2019-10-14T17:43:49Z

ben commented

2019-10-14 17:43:49 +00:00

This would mean using the value of $XDG_CONFIG_HOME or ~/.config if unset: see the spec for more info. This will help prevent additional dotfiles piling up in users' homedirs.

There could be a fallback:

$XDG_CONFIG_HOME/bombadillo/bombadillo.ini
$XDG_CONFIG_HOME/bombadillo.ini
~/.bombadillo.ini

This would mean using the value of `$XDG_CONFIG_HOME` or `~/.config` if unset: see [the spec](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) for more info. This will help prevent additional dotfiles piling up in users' homedirs. There could be a fallback: 1. `$XDG_CONFIG_HOME/bombadillo/bombadillo.ini` 2. `$XDG_CONFIG_HOME/bombadillo.ini` 3. `~/.bombadillo.ini`

sloum added the

enhancement

non-functional

labels 2019-10-14 17:58:55 +00:00

sloum commented

2019-10-14 17:59:00 +00:00

This is interesting. I had not heard about this. A quick look shows that none of my machines seem to have this set by default. However, support for this should be reasonably possible.

I'll read more about this, but a preliminary look seems like it would be a good fit.

I'm trying to institute a feature freeze right now for v2.0.0, in order to finally get it completed as an official release (so only fixing bugs, working on the makefile/packaging, and documentation). I'll think on whether this should be put in as a last minute add-in or bumped to v2.1.0, but I think it likely it will make it in at some point in the not distant future.

I'll keep this issue open and comment as things develop.

This is interesting. I had not heard about this. A quick look shows that none of my machines seem to have this set by default. However, support for this should be reasonably possible. I'll read more about this, but a preliminary look seems like it would be a good fit. I'm trying to institute a feature freeze right now for v2.0.0, in order to finally get it completed as an official release (so only fixing bugs, working on the makefile/packaging, and documentation). I'll think on whether this should be put in as a last minute add-in or bumped to v2.1.0, but I think it likely it will make it in at some point in the not distant future. I'll keep this issue open and comment as things develop.

sloum commented

2019-10-16 01:08:31 +00:00

@ben I just realized that this is a configuration setting that an administrator can already make at compile time. If you look in defaults.go you will see a number of settings that are meant to be changed by the person compiling the program. I will be updating the readme to make this clear before 2.0.0 is released. That said, I added some notes (in one of the branches awaiting a PR into develop that comments out the exact setting you are wanting to have updated.

I am going to leave this issue open until I update the README and then close it, unless there are further comments or the defaults file cannot be used to achieve your goal.

I am in favor of this approach as it requires no code to implement, the functionality is already there. It also provides flexibility for differing opinions on where a file of this sort should go: each person compiling the program can set it as best fits their system.

@ben I just realized that this is a configuration setting that an administrator can already make at compile time. If you look in `defaults.go` you will see a number of settings that are meant to be changed by the person compiling the program. I will be updating the readme to make this clear before 2.0.0 is released. That said, I added some notes (in one of the branches awaiting a PR into `develop` that comments out the exact setting you are wanting to have updated. I am going to leave this issue open until I update the `README` and then close it, unless there are further comments or the `defaults` file cannot be used to achieve your goal. I am in favor of this approach as it requires no code to implement, the functionality is already there. It also provides flexibility for differing opinions on where a file of this sort should go: each person compiling the program can set it as best fits their system.

asdf commented

2019-10-17 03:46:43 +00:00

Good suggestion @ben , I've seen a lot of people talking about filling up home directories with dot files, and had thought about this myself.

@sloum - having the compile-time configuration in defaults is useful to address this request. I'm in favour of this approach for now. Perhaps this could be changed to ~/.config/bombadillo.ini as the default setting.

My own interpretation of implementing XDG config spec would be that bombadillo should choose a configuration file location, in the following order:

Whatever is set in the defaults file (which would be blank by default, but allows override)
$XDG_CONFIG_HOME (if set)
$HOME/.config/
$HOME (read only, for backward compatibility only - no new config files to be saved here)

This way, new config files would sit in the appropriate location, but the existing way of working would not be affected.

If this approach is something we could agree upon, I can implement it in a couple of weeks time.

Good suggestion @ben , I've seen a lot of people talking about filling up home directories with dot files, and had thought about this myself. @sloum - having the compile-time configuration in defaults is useful to address this request. I'm in favour of this approach for now. Perhaps this could be changed to `~/.config/bombadillo.ini` as the default setting. My own interpretation of implementing XDG config spec would be that bombadillo should choose a configuration file location, in the following order: 1. Whatever is set in the `defaults` file (which would be blank by default, but allows override) 1. `$XDG_CONFIG_HOME` (if set) 1. `$HOME/.config/` 1. `$HOME` (read only, for backward compatibility only - no new config files to be saved here) This way, new config files would sit in the appropriate location, but the existing way of working would not be affected. If this approach is something we could agree upon, I can implement it in a couple of weeks time.

sloum commented

2019-10-17 20:09:56 +00:00

Having thought about it more I'm in favor if just having admins set it in the defaults rather than add logic to look in different places. The structure exists already, and admins or individual users can set this easily to suit the needs of their system.

While I would not in say that Bombadillo follows the suckless philosophy of code compactness... I do feel like this is the exact situation that they try to prevent in their software: lots of checks and backups to checks for settings that could just get set once in a static file.

Personally I prefer everything being in ~, so that may be a part of my resistance; combined with what I view as code bulk forming in places that do not do much to make Bombadillo a better client for its intended purpose.

That all having been said, if you think it better to go the other way @asdf I am open to it, but I would want it to be pushed to a 2.0.1+ release. My one request in that instance is that item 4 gets changed to read and write, as I do not like the idea of restricting how a user structures their filesystem.

Having thought about it more I'm in favor if just having admins set it in the defaults rather than add logic to look in different places. The structure exists already, and admins or individual users can set this easily to suit the needs of their system. While I would not in say that Bombadillo follows the suckless philosophy of code compactness... I do feel like this is the exact situation that they try to prevent in their software: lots of checks and backups to checks for settings that could just get set once in a static file. Personally I prefer everything being in `~`, so that may be a part of my resistance; combined with what I view as code bulk forming in places that do not do much to make Bombadillo a better client for its intended purpose. That all having been said, if you think it better to go the other way @asdf I am open to it, but I would want it to be pushed to a 2.0.1+ release. My one request in that instance is that item 4 gets changed to read _and_ write, as I do not like the idea of restricting how a user structures their filesystem.

sloum added the

non-urgent

label 2019-10-17 20:16:10 +00:00

asdf commented

2019-10-18 21:53:07 +00:00

Really good points @sloum , I wouldn't want to add unnecessary bloat and complexity where it adds little value. Nor should any further work delay the release.

For reference, this article is how I know about the xdg base dirs, and you can see it comes from a (very emotive) desire to have less in the root of home (which is already possible). It could also be considered a desire to store application data in a standard way.

A minimal way of implementing this would be to have a function that just does the XDG config path thing (return $XDG_CONFIG_HOME if set, or $HOME/.config/). In defaults.go, the new function can be optionally used:
"configlocation": NewFunction()
It could even be an inline, anonymous function in defaults.go (maybe?).

What do you think of this approach?

Really good points @sloum , I wouldn't want to add unnecessary bloat and complexity where it adds little value. Nor should any further work delay the release. For reference, [this article](https://0x46.net/thoughts/2019/02/01/dotfile-madness/) is how I know about the xdg base dirs, and you can see it comes from a (very emotive) desire to have less in the root of home (which is already possible). It could also be considered a desire to store application data in a standard way. A minimal way of implementing this would be to have a function that just does the XDG config path thing (return `$XDG_CONFIG_HOME` if set, or `$HOME/.config/`). In `defaults.go`, the new function can be optionally used: "configlocation": NewFunction() It could even be an inline, anonymous function in defaults.go (maybe?). What do you think of this approach?

sloum commented

2019-10-19 02:38:59 +00:00

I am ok with this approach. It fits a nice balance between not forcing a behavior and not adding too much code for this feature.

something like the following might work:

func xdgConfigPath() string

func homeConfigPath() string

having both of those in the defaults.go file (with solid commenting) should let someone easily choose the one that fits best. I originally thought combining it into a single function and passing a bool might be good, but the naming inherent in having both makes things more clear when you are reading the defaults map.

Above the default in question we should show three examples: the xdg function, the home function, and then let people know they can just write a path if they prefer. I'd like non-developers to be able to set up their config and I think moving the logic into functions helps with that (when we provide the calling syntax in a comment).

This has a green light from me.

The only question that remains is which default does it ship with as the official default? I am still in favor of home, but I am happy to have this exact issue written up in the readme so that people can know the options are there and how to set them.

I am ok with this approach. It fits a nice balance between not forcing a behavior and not adding _too_ much code for this feature. something like the following might work: ``` func xdgConfigPath() string func homeConfigPath() string ``` having both of those in the defaults.go file (with solid commenting) should let someone easily choose the one that fits best. I originally thought combining it into a single function and passing a bool might be good, but the naming inherent in having both makes things more clear when you are reading the defaults map. Above the default in question we should show three examples: the xdg function, the home function, and then let people know they can just write a path if they prefer. I'd like non-developers to be able to set up their config and I think moving the logic into functions helps with that (when we provide the calling syntax in a comment). This has a green light from me. The only question that remains is which default does it ship with as the official default? I am still in favor of home, but I am happy to have this exact issue written up in the readme so that people can know the options are there and how to set them.

asdf added this to the 2.0.0 milestone 2019-10-31 03:29:59 +00:00

asdf self-assigned this 2019-10-31 03:30:04 +00:00

asdf commented

2019-11-12 07:09:08 +00:00

Hi @ben

Support for XDG config home / base directories is now implemented in the develop branch. The configuration file .bombadillo.ini will be read from XDG_CONFIG_HOME if it exists, or ~/.config if it doesn't.

If you get some free time, please feel free to try it out and let us know if it works as you expect.

Thanks for raising this issue! Let us know if there's anything else that comes up.

Regards,
asdf

Hi @ben Support for XDG config home / base directories is now implemented in the develop branch. The configuration file `.bombadillo.ini` will be read from `XDG_CONFIG_HOME` if it exists, or `~/.config` if it doesn't. If you get some free time, please feel free to try it out and let us know if it works as you expect. Thanks for raising this issue! Let us know if there's anything else that comes up. Regards, asdf

asdf commented

2019-11-19 01:17:26 +00:00

Hi @ben

I'll close this issue off as the feature has been implemented in the develop branch for a while now. We will let you know when the 2.0.0 release occurs, which will include your suggested feature.

Thanks again!

Hi @ben I'll close this issue off as the feature has been implemented in the develop branch for a while now. We will let you know when the 2.0.0 release occurs, which will include your suggested feature. Thanks again!

asdf closed this issue

2019-11-19 01:17:26 +00:00

Sign in to join this conversation.