Closed ejiektpobehuk closed 3 years ago
I think colours is the killer feature of a dstask config file. I'm unconvinced about allowing a choice of file format, yaml works fine and I'd rather not increase the code complexity/size for no real benefit.
I'm not sure there is any gain from writing cutom config parsing. We can use something like spf13/viper.
regarding colors, i would suggest this approach: 1) a file per theme, where a theme defines all colors used and similar visualization settings 2) in the config file, you define which theme you want to use.
this way, people can easily share and diff themes, and you can easily try out many
i note that viper is fairly heavyweight. i presume we probably just want to read a simple file with some fields, so a simple toml library will do the job potentially we may want to allow to control some, or all, of the config values via environment variables. this is where a more advanced library starts to become relevant.
cristalhq/aconfig is a much lighter alternative to viper which still allows to get values from files, arguments, envs. Man-oh-man, I love the ability to override stuff with direnv
To add my 2 cents as a new user:
Configuring the location of the repo would be nice, but if you want it somewhere else, I assume you could simply use a symlink.
I cannot see any value in making the format configurable. It adds complexity for no benefit (at least I cannot see any). yaml is perfect (as would be toml or json or whatever). dstask is supposed to be opinionated and should have an opinion about the format. No need for any change here as far as I am concerned.
Configuring the colours would have a big benefit. But I think there is only a handful of colours to be configured - no need for a config-file.
In general I love the idea of configuration via environment-variables. No need for config-file parsing and all that could go wrong there. It's easy to say a config-file has a syntax-error. But if you want to provide proper error reporting that would be useful to the user it amounts to work - for what benefit?
So I would use something like (eg) DSTASK_P2_FG=red in the environment to configure the colours.
* Configuring the location of the repo would be nice, but if you want it somewhere else, I assume you could simply use a symlink.
Already supported with DSTASK_GIT_REPO
(just not documented yet -- it's used by the tests)
* I cannot see any value in making the format configurable. It adds complexity for no benefit (at least I cannot see any). yaml is perfect (as would be toml or json or whatever). dstask is supposed to be opinionated and should have an opinion about the format. No need for any change here as far as I am concerned.
Yes I have no intention of supporting multiple configuration formats for that reason. In fact, I think environment variables may do considering there isn't (and won't be) much to configure.
* Configuring the colours would have a big benefit. But I think there is only a handful of colours to be configured - no need for a config-file.
So I would use something like (eg) DSTASK_P2_FG=red in the environment to configure the colours.
I was thinking something like how LS_COLOURS
works. Maybe DSTASK_COLOURS=32:52:23:23:52:93
or something.
Good idea. I would like to have a way to both configure the colours and to turn them off completely.
Mayby check if stdout is a tty.
If no tty => no colours. If tty and no DSTASK_COLOURS => use defaults If tty and DSTASK_COLOURS=... => use that If tty and DSTASK_COLOURS=none => no colours
Maybe DSTASK_COLOURS=32:52:23:23:52:93 or something.
so cryptical. if we're going to have a config directory (as per XDG), then having a file that defines colors in a human friendly way has no real cost.
Sure, if we actually want a config file. I'm on the fence atm; though it does seem we'll eventually need one due to the number of options required; that said I'd rather not make dstask too configurable.
Closing as no need for a config file at present. Please open a separate issue for DSTASK_COLOURS
Oh, there is one https://github.com/naggie/dstask/issues/110
There is a config file location discussion (#49) but no issue to discuss config itself. So here it goes 🚀
I see two main topics:
ps. I would really love to configure colors. pps. Imagine having different colors for different projects with direnv...