Default `bacon.toml` overrides `prefs.toml` configured jobs

[Nemo157]

I have some default jobs to use on projects that haven't configured bacon themselves in my prefs.toml. To use them I still need to touch bacon.toml in each project to stop the default package config overriding my system configuration. It feels like these defaults should not override anything that has been explicitly configured in prefs.toml.

[Canop]

Right now I don't really see how to handle your concern in a convenient and obvious way but it's noted, thanks.

[Jeidnx]

It would be awesome if this behavior was mentioned on the config page. I tried to add some env vars to the default run job and i was really confused why they weren't applying. I ended up creating a new job and binding that to r instead.

[ArielHorwitz]

TL;DR - My suggestion for a convenient and obvious way to solve this concern would be to add one more file ~/.config/bacon/config.toml that overrides all other files (including project-specific configuration). This would allow a user to override settings and configure bacon personally without making changes in version-controlled project files.

---

I just ran into this and it is extremely confusing. I see that my prefs.toml is being loaded (seeing as the custom jobs existed) but I couldn't understand why the default_job wasn't being respected. This was "solved" by running touch bacon.toml as mentioned by @Nemo157 - however this is not a great solution because it is a version controlled file which is not always possible to modify.

The website mentions:

All accept the same properties (preferences, keybindings, jobs, etc.). The properties of the global prefs.toml file are overriden by the workspace level bacon.toml file, then by the package level bacon.toml file.

One would assume that without creating a bacon.toml file, the prefs.toml file would actually be useful for "the same properties". However now I understand there is an implicit bacon.toml file overriding my prefs.toml file that makes the prefs.toml almost useless. Confusion could be averted if the implicit default bacon.toml file did not define anything (or was not implicit) -- and those jobs and preferences would be defined in the default prefs.toml instead.

The fact that the highest-priority configuration is in a version controlled file within the project directory means that in order to make bacon's configuration useful for me I must commit an empty bacon.toml file into every project, and it isn't useful at all in projects where I cannot commit such a file.

[Canop]

Situation should be better with https://github.com/Canop/bacon/pull/203

It's possible it breaks some workflows, but probably not many ones and it looks saner.

Comments welcome.

[ArielHorwitz]

IMO #203 is "correct" (expected) behavior and is a welcome change.

I can suggest an alternative solution to avoid "breaking changes":

1. Add another highest-priority config file (e.g. ~/.config/bacon/config.toml)
2. In the next major version, move all defaults from the default bacon.toml to the default prefs.toml

1 and 2 are not mutually exclusive: I see no benefit for a project to override my own personal hotkeys, so I should still be able to override bacon.toml. @Canop, would you also be interested in a PR for suggestion 1? This should also solve this issue ( #157 ).

[Canop]

IMO there are already enough configuration file and, unless I miss something, adding one would add to confusion.

I might, at some point, move some of the settings of the default bacon.toml to a hardcoded internal config, but I'd rather do it later to minimize changes now (and because there doesn't seem to be a real need).

[Canop]

I should make a new release of bacon (2.20.0) with this change in a few hours.

[Canop]

I made the release