Config file

[tkellogg]

Config file

[chand1012]

@JakeStanger this is awesome! Good work!

[tkellogg]

your second point is very strong. go for it

[JakeStanger]

Going to start work on this today

[tkellogg]

I have a JSON file in ~/.config/dura/config.json. It's a misnomer though because its more of a "runtime database", not for humans to edit. For config, I was thinking rename that file to runtime.db (still JSON) and create another called config.toml. Alternately, we could use .gitconfig, but I like the TOML option better because we could include all available options and document them extensively. Harder to do that with .gitconfig. What do you think?

[chand1012]

I think the format of a .gitconfig is great, but we should avoid using the existing one as it's bad practice to use another programs config file. I think TOML makes the most sense. Renaming the file to have .db or even calling it something like paths.json would be better for less confusion.

[JakeStanger]

Given my PR above, I think now is a good time to work on this.

Correct me if I'm wrong, but the only value that should be inside the db file at the moment is the pid. The rest can be put inside a human-friendly config.

Ideally, the db should be put in the user's cache dir, and the config inside their config dir.

[tkellogg]

One reason to keep the paths in the DB is as a cache. But that comes with all the problems of caches, so I'm fine getting rid of it and just having the PID in the DB.

[tkellogg]

Some guidelines:

• JSON for machine-writable content. Since dura watch and dura unwatch exist, shouldn't we store these in JSON?
• TOML for things that need lots of documentation. We can put lots of comments in a default config file with all available options

Those aren't entirely opposites, and the paths config seems to fall under both.

[JakeStanger]

My feeling is that paths should definitely be part of the config:

• They're defined by the user: watch and unwatch are end-user commands for configuring the program behavior

• The config should contain everything required to duplicate the setup. I should be able to copy config.toml to a new machine (with a similar file structure) and dura just work

• Cache files should be treated as temporary. If paths were part of the cache and the cache got wiped, you'd need to reconfigure the program

• One reason to keep the paths in the DB is as a cache

  I'd stay well clear of trying to cache a list of files on disk. As you mention it brings about a lot of problems, and I think if it becomes necessary that would suggest a larger architectural problem. I know somebody mentioned using notify to listen for file changes which should come with enough performance benefits to remove any possible need for caching.

[JakeStanger]

@chand1012 changes were merged this evening, obviously more settings will get added with time but let me know what you think :)

.config/dura/config.toml (you'll need to watch a dir for it to be generated)