google / yamlfmt

An extensible command line tool or library to format yaml files.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consider to change/improve configfile discovery

netzego opened this issue · comments

  1. $PWD/.yamlfmt
  2. $HOME/.yamlfmt
  3. $XDG_CONFIG_HOME/yamlfmt/config or .../yamlfmt/yamlfmt (without a dot)
  4. /etc/yamlfmt/config

The finding algo should search upwards from the current working dir. This helps to prevents spamming .yamlfmt files all over the repo dirs. Without this feature it is very hard to track/change settings.

Imho, dot files inside $XDG_CONFIG_HOME are not useful.

A system wide place eg. etc would be nice.

Thx for considering and your work.

Hi @netzego thanks for making an issue!

Introducing $XDG_CONFIG_HOME config location was designed specifically to deal with not needing a .yamlfmt in every repo.
Can you expand on why you think dot files inside $XDG_CONFIG_HOME isn't useful? If there is some difference with a dotfile being in $XDG_CONFIG_HOME over a normal file, I don't know what it is.

I might be able to consider a system-wide location, but it would need to be cross-platform with Windows or I'd need to find a super compelling reason to break cross-platform compatibility there.

@braydonk sure:

  1. $XDG_CONFIG_HOME is a dotfile/folder itself. so lets take a look at for e.g. git it uses $XDG_CONGIF_HOME/git/config. It's common to not use dot files inside $XDG_CONFIG_HOME. ls -1 $XDG_CONFIG_HOME/*/.* | wc -l is equal to 1 on my system. and that is from .yamlfmt :) When i would go into a dir inside $XDG_CONFIG_HOME which contains a dotfile, chances are that i would consider it empty--without noticing the hidden file.

  2. You got me wrong, that's my fault. What i meant is. It is often useful to have different configurations for different repos. With XDG_CONFIG_HOME it is only possible to have one configuration for all repos. But what if one need an other config in repo A then repo B? Then one have to use .yamlfmt files in the $PWD. Now lets consider this dir struct in a repo:

repo
└── src
    ├── a
    │   └── aa.yml
    ├── b
    │   └── bb.yml
    ├── c
    │   └── cc.yml
    └── zz.yml

To use yamlfmter one have to put a .yamlfmt in all folders (src, src/a, src/b and src/b) but not in repo. Most parsers and linters would honor .yamlfmt in repo root dir. They sort of searching upwards the $PWD dir until they found a .yamlfmt file. And if no file is found only then the tool tries to load $XDG_CONFIG_HOME and others. I suggest you implement this as well. That's what i meant with spamming .yamlfmt files all over.

On "cross-platform compatibility" is $XDG_CONFIG_HOME a thing in m$, nowadays?

On XDG_CONFIG_HOME:

What you mention re putting the dotfile directly into $XDG_CONFIG_HOME, I don't think that's what yamlfmt does. It actually does look for $XDG_CONFIG_HOME/yamlfmt/.yamlfmt. So $XDG_CONFIG_HOME/.yamlfmt shouldn't be a thing and probably shouldn't work. If it does I will try and fix it.

It is a thing in Windows; it defaults to $HOME/AppData/Local.

On the search upwards:

Thanks for the explanation it makes more sense now, I think I can make this work in my upcoming revamp of config loading.

What you mention re putting the dotfile directly into $XDG_CONFIG_HOME

No, that's not what i mentioned, did i? I did not wrote $XDG_CONFIG_HOME/.yamlfmt! No additional dot files inside $XDG_CONFIG_HOME, as it is already a dotfile. There is no need to "hide" files inside a XDG. No one does it, at least on my system, yamlfmt is the exception here. I mean, that's really not my main concern here. I just wanna make myself clear :) The main thing is the search upwards.

Sorry for the misunderstanding. I will be adding support for yamlfmt.{yml,yaml} when I address #122 (as well as .yamlfmt.{yml,yaml}).

#122 makes also sense. So $XDG_CONFIG_HOME/yamlfmt/yamlfmt.yml and $PWD/.yamlfmt.yml? It's good. Thanks for your time!

The work for this is done and released in v0.11.0