add support for writing arbitrary dotfiles

[jordanglassman]

Support for extensionless and dotenv files has been added, and for reading any file, but commonly used arbitrary dotfiles are not supported at the write stage:

func Test_anyDotfileSupport(t *testing.T) {
	viper.SetConfigName(".some-dot-file")
	viper.SetConfigType("yaml")
	err := viper.WriteConfigAs(filepath.Join("/tmp", ".some-dot-file"))
	if err != nil {
		t.Errorf("no dotfile support, e=%s", err.Error())
	}
}

=== RUN   Test_anyDotfileSupport
    Test_anyDotfileSupport: common_flags_test.go:35: no dotfile support, e=Unsupported Config Type "some-dot-file"
--- FAIL: Test_anyDotfileSupport (0.00s)
FAIL

[greg-szabo]

Duplicate of #427
Proposed fix in #934

[jordanglassman]

Thanks @greg-szabo.

Friendly observation that the fix in #934 is still probably sub-optimal for this case since

	viper.SetConfigName(".some-dot-file")
	viper.SetConfigType("some-dot-file")

feels a bit kludgy to be.

Another possibility would be to support dotfiles with any extension, eg.:

	viper.SetConfigName(".some-dot-file")
	viper.SetConfigType("dotfile")

[greg-szabo]

Ah, interesting, thanks for pointing it out. #934 fixes the original example in this issue, where you have a random filename with a random extension and you want to force it to be a yaml configuration.

I guess it needs more clarification what exactly you want to achieve. As far as I understand .env files (and the file extension ".env") are supported in the code. The configtype for these are dotenv or env.

I don't know if Viper supports "files that start with a dot" somehow differently. The WriteConfig code currently definitely looks for a file extension to figure out what type of file it should write, so if you have a filename that starts with dot and continues with a random string (not env or dotenv specifically or any other of the SupportedExts) then it won't be able to figure out that you want to write a .env-type file. You will have to specifically tell Viper viper.SetConfigType("dotenv"). BUT, this will only work if #934 is implemented, because as mentioned above, file extensions take precedence, currently.

To summarize: currently, you have to name your file explicitly .env, .dotenv or somename.env to be able to write your dot-env-type file. With the change in #934, you could do it with any file name, as long as it's established that it's a dotenv file.

[jordanglassman]

My observation is just that, arbitrary dotfiles are quite common as config files, of any type (yaml, env, etc.).

After #934, it will be possible to support those files with something that feels a bit hacky:

	viper.SetConfigName(".gitignore")
	viper.SetConfigType("gitignore")

which IIUC only works correctly if it's a dotenv file (not eg. yaml).

A future refactor might just require SetConfigType if the first char is a ..

[greg-szabo]

Nope, that's not the case (I mean the hacky solution is not the case). I think you're misusing SetConfigType there. The only valid SetConfigType strings are defined in SupportedExts mentioned above. It seems that it accepted the string, but when you try to save the file, it will complain that it's an Unsupported Config Type.

Currently, if your file name is .gitignore, you have no way of saving the file with Viper's WriteConfig. It will complain that your file is unsupported, regardless of what you are trying to do.

After implementing #934, this will be a valid way to save the config file:

viper.SetConfigFile(".gitignore")
viper.SetConfigType("dotenv")
viper.WriteConfig()

Essentially, #934 allows you to write arbitrary dotfiles, as you requested in the issue. The only thing you need to change in the above code is the file name. The ConfigType will always be dotenv, yaml, json or whatever type the file actually contains. It will not be the extension of your file.

This is literally the "another possibility" you mentioned in your comment. It's already implemented, only it's not called "dotfile", it's called "dotenv". And it's missing the change in #934 to actually work.

I have different reasons to request #934. If you want to push a different solution, that's fair. I was just trying to help.