[moved] NIM_CONF: allows passing in custom config before all others and apply to sub-processes

[timotheecour]

motivating example

Whenever nim introduces a (necessary) breaking change (eg; -d:nimLegacyX flags), some packages in important_packages may break, and are then either disabled or their nimble command is patched as follows:

nimble test foo
=>
nimble test foo -d:nimLegacyX

nim r tests/tbar
=>
nim r -d:nimLegacyX tests/tbar

however, this may not be enough, because tests (or nimble) may call (eg via nimscript exec or nim execShellCmd or other) further nim compilation commands, which won't have such flags propagated.

proposal

allow a simple way to pass a user config that would then automatically apply to all nim invocations via sub-processes.

We add an environment variable NIM_CONF: NIM_CONF=/pathto/customconf.nims nim args...

When NIM_CONF is non-empty, the file contained in NIM_CONF would be the 1st config file processed before all others (system, user, parent, project).

This gives the maximum flexibility (eg: allows honoring/ignoring further configs, setting --putenv, setting -d:nimLegacyX, setting --path, setting --putenv:NIMBLE_DIR, setting --gc:orc, etc)

alternative considered and rejected

set HOME or XDG_CONFIG_HOME to a custom (temporary) dir which would have the custom configuration, eg:

nimble test
=>
XDG_CONFIG_HOME=/pathto/tempHomeConfig nimble test

then CI would create /pathto/tempHomeConfig and /pathto/tempHomeConfig/nim/config.nims
containing for example:
-d:nimLegacyX

one problem is that XDG_CONFIG_HOME is os-specific (IIRC); furthermore, setting HOME or XDG_CONFIG_HOME can have other side effects

use cases

• when a nim PR must introduce a breaking change and we want to add -d:nimLegacyX to a test command (eg nimble test) and ensure it applies to all further nim invocations
• when nim wants to test important_packages in more configurations (eg: --gc:orc) to see what breaks or ensure a flag works for regression purposes

design goals

• not having to patch such packages
• make it simple to use once this feature is implemented

implementation difficulty

• probably quite easy, it's a simple update to the config processing
• this could be backported all the way to 1.0.x

[timotheecour]

=> nim-lang/RFCs#336