96 lines
4.2 KiB
Markdown
96 lines
4.2 KiB
Markdown
|
# Config files and their problems
|
||
|
|
||
|
2023-08-18
|
||
|
|
||
|
Today I want to talk a bit about configuration files as well as their issues,
|
||
|
and believe me, there are many issue with configuration files.
|
||
|
|
||
|
## The suckless approach
|
||
|
|
||
|
The suckless approach for those unaware is to never use config files. Instead,
|
||
|
with suckless software you modify a `config.h` header which contains variables
|
||
|
intentionally exposed to the user. Then you simply rebuild the software with
|
||
|
the options chosen built into the binary.
|
||
|
|
||
|
Many issues with regular configuration files are not a problem here. We'll get
|
||
|
into those problems in a bit, but doing it this way introduces many other
|
||
|
potential problems. The most notable issue is having to recompile the program
|
||
|
every time you want to change one small thing, such as the colorscheme or a
|
||
|
keybind.
|
||
|
|
||
|
In any case, most of the problems with regular configuration files do not apply
|
||
|
to suckless software, simply because of how it is designed.
|
||
|
|
||
|
## Problems with configuration files
|
||
|
|
||
|
- Options get deprecated
|
||
|
|
||
|
This is what compelled me to write this blog post. Although not a problem with
|
||
|
configuration files directly, developers naturally often feel the need to
|
||
|
deprecate options in their configuration files, but this is incredibly poorly
|
||
|
handled most of the time leaving the user suffering.
|
||
|
|
||
|
Let's take Hyprland for instance. Hyprland wants to be this compositor which
|
||
|
always implements the latest and greatest, and as a result they do not at all
|
||
|
care if they drop support for options the user has in his or her
|
||
|
configuration file. After updating Hyprland I received a warning because I had
|
||
|
used a now deprecated option in my configuration file. This option is simply a
|
||
|
toggle for blur.
|
||
|
|
||
|
A sensible developer would deprecate the feature and in case a replacement exists,
|
||
|
simply rewrite the user's config file on runtime to use the new replacement.
|
||
|
As a result, the user can use the old configuration file with the new program and
|
||
|
everyone is happy. If a replacement option does not exist, you should probably
|
||
|
simply ignore the line. In the rare case that a option MUST be removed, the major
|
||
|
version should be bumped and users should be warned in advance.
|
||
|
|
||
|
A general rule is, if the configuration works right now, it should work in 10
|
||
|
or 20 years with almost no maintainence necessary. This is one area where
|
||
|
suckless software rocks. For the record, I can compile dwm 0.1 from July 2006
|
||
|
on my computer and it will work EXACTLY like it did in 2006. No maintainence
|
||
|
necessary.
|
||
|
|
||
|
- Not very extensible
|
||
|
|
||
|
Configuration files are not very extensible most of the time. Some config files
|
||
|
are more hackable than others, but usually they simply modify variables in the
|
||
|
program itself and nothing more, so writing new code or new functions is usually
|
||
|
not at all trivial and config files usually are not designed around being hackable.
|
||
|
|
||
|
Some config files kind of support functions or similar, notably Waybar.
|
||
|
|
||
|
- Syntax
|
||
|
|
||
|
The syntax can vary. Some programs use Windows style `.ini` files which look something
|
||
|
like this:
|
||
|
|
||
|
```
|
||
|
[myProgram]
|
||
|
Variable = 123
|
||
|
```
|
||
|
|
||
|
While these aren't extensible at all, they make up for that in simplicity,
|
||
|
which is very often desirable, especially if you don't need the program to be
|
||
|
that extensible through a config file. But of course, this format isn't good
|
||
|
for every single use case, so JSON style formats such as YAML are very popular.
|
||
|
|
||
|
That's where the syntax can be a problem. The syntax is usually very
|
||
|
unpredictable and unless a "default" configuration is bundled with the program
|
||
|
the user is likely to be very lost. To make matters even worse, the default
|
||
|
configuration is usually hidden away so the user ends up having to use the
|
||
|
internet to figure it out.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
Alright, so what do I think about configuration files? Contrary to what you
|
||
|
might think, I am not against config files, at least not most of the time. I
|
||
|
even use configuration files in a lot of my software.
|
||
|
|
||
|
However it's worth noting that config files are not without problems, and
|
||
|
while a good developer can work around some of these issues, for example by
|
||
|
simply not deprecating features like a madman, at the end of the day a config
|
||
|
file is written after the program was initially compiled, and that's a big
|
||
|
reason for all of its drawbacks.
|
||
|
|
||
|
That's it for today, have a good day!
|