Nim is a compiled, garbage-collected systems programming language with a design that focuses on efficiency, expressiveness, and elegance (in that order of priority).
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
timotheecour
commented
3 years ago
motivating example
Whenever nim introduces a (necessary) breaking change (eg;
-d:nimLegacyXflags), some packages in important_packages may break, and are then either disabled or their nimble command is patched as follows: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_CONFis non-empty, the file contained inNIM_CONFwould 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
HOMEorXDG_CONFIG_HOMEto a custom (temporary) dir which would have the custom configuration, eg:then CI would create /pathto/tempHomeConfig and /pathto/tempHomeConfig/nim/config.nims containing for example:
-d:nimLegacyXone problem is that XDG_CONFIG_HOME is os-specific (IIRC); furthermore, setting HOME or XDG_CONFIG_HOME can have other side effects
use cases
-d:nimLegacyXto a test command (egnimble test) and ensure it applies to all further nim invocations--gc:orc) to see what breaks or ensure a flag works for regression purposesdesign goals
implementation difficulty