Support config files with no extensions

[pedromss]

Support config files with no extension.

Closes: #390 This was a mistake
Closes: #336

Similar to https://github.com/spf13/viper/pull/357/files which appears to have been forgotten.

Difference is: attempt a no extension right away instead of messing with the extension append and iterating through the extensions.

[CLAassistant]

All committers have signed the CLA.

[gjrtimmer]

Hi, I really want this, any news when it will be merged ?

@pedromss maybe a update of the README is required ?
Maybe some note that if using a config file without extension viper.SetConfigType(...) is required for viper to deserialize the config ?

[pedromss]

@gjrtimmer I don't know what else is required to get this approved. Seems like this repo isn't maintained judging by the state of the PR and issue section

¯_(ツ)_/¯

[dmacvicar]

I like this approach as well.
Can we please merge either this or my own #357, which is open for more than 2 years?

[sagikazarmark]

@pedromss Just for me to understand: you want to explicitly set a config name with an extension?

viper.SetConfigNam("config.yaml")

And you want to search for that specific file within the configured search paths?

Is that correct?

[pedromss]

@sagikazarmark no. The idea is to be able to have configuration files that don't have an extension in their name. As is many times the case with tools which have config files in the home folder for example.

So supporting .toolconf instead of .toolconf.yaml is the goal of this PR

[sagikazarmark]

@pedromss I see. Thanks for the explanation.

[sagikazarmark]

Can you please add a few lines and an example about this feature to the readme? Maybe after the Reading Config Files section.

Apart from that ✔️

[pedromss]

@sagikazarmark please take another look now

[sagikazarmark]

Thanks @pedromss !

[sagikazarmark]

@pedromss actually, I wonder if the condition should be moved after the the loop, to make sure existing behavior isn't broken (eg. there is a config and a config.yaml file in a folder. this PR would break existing code in those cases).

WDYT?

[pedromss]

@sagikazarmark I had thought to resolve it immediately without "unnecessarily" walking the files in the folder. But what you say makes more sense.

Changed it.

[sagikazarmark]

Awesome, thanks!

This is a one time step, so I wouldn't worry about unnecessary checks for non-existing files.

[andig]

I'm a bit confused as to how far this fixes #390. #390 doesn't seem to be about extension-less files?

[pedromss]

You're correct 😕 I must have made a mistake when analysing the issue. Reading it again, I would say this comment #390 (comment) made me think the problem was the no extension, which was a problem in it self but not of that issue.

Thank you. I'll edit this description and reopen #390