NIM_CONF env var: 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, or see nim-lang/Nim#16924), 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...

Environment variables are simplest way to inherit a setting for sub-processes without affecting other processes.

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; this is a better approach than the one proposed in Enable 'some' experimental features by default in devel Nim#16913 since it doesn't impose experimental flags in devel (impacting devel users) but still allows testing experimental flags at scale
• for things like inim, it's impossible to pass flags to nim and make them propagate (eg try the test suite, the best you can do is XDG_CONFIG_HOME=/tmp/customcfg nimble test because it calls inim which itself calls nim; there's no way to forward flags and ensure they get propagated unless you're heavily modifying that package

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

[Araq]

I prefer to pass state around explicitly. With environment variables you ask for trouble like "works on my machine, fails on the CI and works again on half of the production servers".