There's nothing I hate more than text config files

8 thoughts on “There's nothing I hate more than text config files”

1. 2020-06-02 12:08

   

   Neil Brown said on twitter.com:

   This is something @firebrickltd — a GUI for those who prefer to use a GUI, or text access, for those who prefer to edit that.
   
   Or use both, for different things.
   
   (And if you offer only a GUI, please ensure there’s a way to export the config: text is portable.)
   

   Reply | Reply to original comment on twitter.com

2. 2020-06-02 12:21

   

   Tom Morris 🏳️‍🌈 said on twitter.com:

   Have you seen the Fish shell?🐟
   
   To configure it, you run fish_config, it boots up local web server and gives you UI. When you hit save, it writes all the changes to the correct config files (which you can then tweak/override). Much nicer than fiddling with bash/zsh config.

   Reply | Reply to original comment on twitter.com

3. 2020-06-02 12:58

   

   Jon Ribbens says:

   I'm not convinced. Your main issues here appear to be (a) YAML, and (b) poor documentation. YAML is indeed an appalling abomination that should be killed with fire. And a GUI won't save you from poor documentation (a pull-down saying your options for "foo" are "bar", "baz" or "quux" helps little if you've no way of knowing what those values mean or how to choose between them). GUIs are often worse than text configuration files, because they hide detail that you need to understand.

   Reply

   1. 2020-06-02 14:06

      

      @edent says:

      Nope. I'm using YAML in this example. I'd say the same things about JSON, or anything else.
      
      Poor documentation is a problem for text files as well as GUIs. But at least a GUI tells you want fields are, and what valid options you can choose.

      Reply

      1. 2020-06-06 08:31

         

         Martyn says:

         It would imply that the author knew every possible value or was willing to continually track and update his creation as other projects introduced new options. In the example you chose, I'd expect the string to be compared against a similar string in the target platform. Implementing a selection box would potentially hinder adoption on different platforms. This option would likely end up as a freeform text field in any GUI, resulting in very little gain.
         
         Providing a GUI also implies that the application is being configured somewhere that the GUI can be displayed. It may be 2020, but many servers are still handled remotely via the CLI, because it's generally sufficient for task at hand and an efficient use of resources on the target server and bandwidth.
         
         Further more, the authors skill set or time available may not extend to developing a GUI and documenting the app. If the choice was between a configuration GUI with options, but no documentation to tell you what they meant and no GUI, but sufficient documentation to allow you to take a stab at configuring in a text file, which one would you choose?

         Reply

         1. 2020-06-06 12:29

            

            @edent says:

            In the specific case above, we're talking about GitHub services running on GitHub's hardware. They know what is available. If your command-line utility can't tell you what options are available, it is broken.
            
            Providing a GUI doesn't imply that only a GUI can be used. As I said above. Store the resultant file as text, json, xml, yml, or whatever. Let people edit it via SSH if they want. But give people the option of a modern GUI.
            
            Your last point... Most open source software is poorly documented. Even GitHub's documentation for their text based tools is terrible. The Alexa documentation is similarly awful. But a GUI gives discoverability in a way that an empty text file doesn't.
            
            Look, if the config file said:
            
            

            # Set your Foo version here
            
            foo: 1.7
            
            # Valid strings are "1.7" or "2.4". This has not been tested with Foo 3 yet
            
            

            
            
            Then I'd be able to use it almost as easily as a GUI. But almost no one does that.

            Reply

4. 2020-06-02 14:25

   

   Isabel says:

   If there are two options that are mutually exclusive, give them radiobuttons.

   Reply

5. 2020-06-03 03:53

   

   Dave says:

   Everything to do with microservices and docker uses these YAML files and it's terribly confusing! And then they change the schema from version to version, so there's another headache. This is not NPM's fault though, it's GH actions I think you're dealing with. You can publish to NPM via command line (npm publish, once logged in) . But I prefer also using CI builds to run tests etc before publishing to be safe.. I use circleci which uses the same yaml config stuff, but at least I found the documentation to be good.

   Reply