Nim: global user config can override project specific config

Created on 17 Oct 2018  路  7Comments  路  Source: nim-lang/Nim

currently, config files are processed in that order:
all nim.cfg files first
then all config.nims files

eg:

Hint: used config file '/Users/timothee/git_clone/nim/Nim/config/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/.config/nim/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/git_clone/nim/proj/nim.cfg' [Conf]
and THEN:
Hint: used config file '/Users/timothee/.config/nim/config.nims' [Conf]
/Users/timothee/git_clone/nim/proj/config.nims

this is odd, as it makes global/user configs (/Users/timothee/.config/nim/config.nims) override project-specific ones (eg /Users/timothee/git_clone/nim/proj/nim.cfg) (given that flags / options can be set in both)

proposal

process in lockstep instead, example:

global nim.cfg
global config.nims
user nim.cfg
user config.nims
proj nim.cfg
proj config.nims

etc

alternative: depreacte nim.cfg

we could think about whether we plan on deprecating nim.cfg, now that config.nims covers all use cases of nim.cfg (but with more features)

High Priority Path Handling

Most helpful comment

You promised me you wouldn't deprecate nim.cfg. It's nice to have a straightforward config format like that instead of full-blown nimscript.

Well this promise cannot hold forever, can it? Do we want to have two config systems forever?

All 7 comments

Ok. Deprecation of the old config system is tough as long as the new config system is so slow. :-(

(moved the probably unrelated issue details to a new issue: https://github.com/nim-lang/Nim/issues/9450)

Ok. Deprecation of the old config system is tough as long as the new config system is so slow. :-(

You promised me you wouldn't deprecate nim.cfg. It's nice to have a straightforward config format like that instead of full-blown nimscript.

@kaushalmodi this is odd (and IMO unrelated to this issue since it's not in lockstep); maybe create another issue and put as much info as needed and let's follow up your issue there instead of here? not seeing your issue on my system.

You promised me you wouldn't deprecate nim.cfg. It's nice to have a straightforward config format like that instead of full-blown nimscript.

Well this promise cannot hold forever, can it? Do we want to have two config systems forever?

let's discuss whether nim.cfg should be deprecated in a separate place => see: should we deprecate nim.cfg in favor of config.nims format? - Nim forum to avoid conflating issues and give everyone a chance to present their arguments

what about config/nimdoc.cfg ?

git clone https://github.com/kaushalmodi/std_vector && cd std_vector # as of ffa9155f24e01b65a267fcd7d6d382a1f7d0a527
nim doc --hint:conf -b:cpp $nim_D/std_vector/src/std_vector.nim
Hint: used config file '/Users/timothee/git_clone/nim/Nim_devel/config/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/git_clone/nim/Nim_devel/config/config.nims' [Conf]
Hint: used config file '/Users/timothee/.config/nim/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/.config/nim/config.nims' [Conf]
Hint: used config file '/Users/timothee/git_clone/nim/std_vector/config.nims' [Conf]
Hint: used config file '/Users/timothee/git_clone/nim/Nim_devel/config/nimdoc.cfg' [Conf]
Was this page helpful?
0 / 5 - 0 ratings