# 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!