• aard@kyu.de
    91·
    6 months ago

    All my software can be configured using dedicated configuration files (.c)

  • aodhsishaj@lemmy.world
    19·
    6 months ago

    Hasn’t this been best practices since Grace “Light has a speed limit” Hopper? May she rest in power.

  • Dark Arc@social.packetloss.ggEnglish
    9·
    6 months ago

    I agree with this, but there are ways to make your “source code” not a file that you will modify.

    For instance you can have a file that’s imported/included for configuration purposes that you yourself don’t author… And I think that’s okay.

    One of my favorite configuration languages for Python projects is actually just Python. It’s remarkably nice. It’s like having a YAML file you can script.

    • maiskanzler@feddit.de
      5·
      6 months ago

      The line between configuration is very messy anyways. So many projects abuse YAML as a domain specific language. Looking at you, HomeAssistant and ESPHome!

      • brisk@aussie.zone
        21·
        6 months ago

        I assume less custom configs are better, but I’ve seen Ansible yaml files that are just convoluted bash scripts written in yaml, which makes them even more convoluted.

        • maiskanzler@feddit.de
          1·
          6 months ago

          Yeah that occurred to me as well. Then I immediately think that maybe we need ☆one more language☆ to fix this. And then I remember that one xkcd comic…

    • lysdexic@programming.devEnglish
      52·
      6 months ago

      It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.

      For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.

  • bizdelnick
    91·
    6 months ago

    1. Options. We’ve got lots of them. So many in fact, that you need two strong people to carry the documentation around. So many that it will be a cold day in hell before half of them are used. So many that you are probably not going to do your work right anyway. However, the number of options isn’t all that important, because we picked some interesting values for the options and called them …

    2. Defaults. We put a lot of thought into our defaults. We like them. If we didn’t, we would have made something else be the default. So keep your cotton-pickin’ hands off our defaults. Don’t touch. Consider them mandatory. “Mandatory defaults” has a nice ring to it. If you change them and your system crashes, tough. See Figure 1.

  • FizzyOrange@programming.dev
    81·
    6 months ago

    Not sure I buy this. If you have a config header file and make backwards incompatible changes to it how is that different to having backwards incompatible changes to any other config system?

    I think what the author meant to say is “don’t make breaking changes to your config system”. Maybe it’s common to ignore that when using source code as config; I don’t know.

    It’s a bad idea anyway because compile-time options should generally only be for configuring the presence of optional third party dependencies, which you can do automatically. Anything else should be a runtime option.

    • Ethan@programming.devEnglish
      3·
      6 months ago

      I think the author’s primary point is, “Merging changes sucks, don’t make your users do that,” with a corollary: if your program loads configuration from a directory that is only populated by the user, there’s nothing to merge and thus never any merge conflicts. Case in point: /etc/polkit-1/rules.d. I can add whatever rules files I want in there and they’re never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That’s a hell of a lot easier than merging conflicting changes to code/configuration.

        • Ethan@programming.devEnglish
          1·
          6 months ago

          True, but if you read the article the point is clearly not about source code vs non-source configuration. There’s an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, “Don’t make users merge changes.”

  • abhibeckert@lemmy.world
    51·
    6 months ago

    For edge cases where you need the power of a programming language in your config system, use something like PKL.

    • Dark Arc@social.packetloss.ggEnglish
      2·
      6 months ago

      Okay, that’s pretty cool not going to lie. Granted, I’m not entirely sold on the idea of having a config format that’s aimed at generating other config formats.

      That feels like (in most cases) a recipe for things getting out of sync between the latest version of the PKL and e.g. the JSON

  • Deebster@programming.dev
    1·
    6 months ago

    I’ve often thought that something like git’s auto-merge would make like much easier when I get asked if I want to keep my config, use upstream or decide per-line. What I should be able to do is have the system pick whichever changed recently, and give me the results to review and/or fix conflicts.