fixes #25235; skipParentCfg in nim.cfg

[Graveflo]

fixes #25235
in commands.nim and options.nim

• adds a new config option skipParentDetectionMode that determines if we are checking for skipParentCfg
• checks if we are in skipParentDetectionMode in processSwitch to ignore all cfg entries except skipParentCfg

in loadConfigs:

• iterates the parentDir to root instead of from root to find the first instance of skipParentCfg
• sets skipParentDetectionMode and disables side effects in parseDirective while in this mode
• creates temp seq of paths that contain a cfg file to process later
• cuts the process short if skipParentCfg is found, so we are left with a list of cfgs to process
• iterates the tmp seq in reverse to get the "from root" behavior and only processing cleared paths

[ringabout]

What happens to --skipParentCfg in .nims files?

[Graveflo]

No change to --skipParentCfg in .nims files after this PR. That is going to require significantly more invasive changes and it's not worth it. configEnablesSkipParent should only be applied to nim.cfg files as this happens after the system configs have been loaded in and before the final compilation target specific one.

Now that you mention it though, I think this is wrong because module specific configs have to be checked too:

Nim/compiler/nimconf.nim

Line 299 in 3f75c15

if optSkipParentConfigFiles notin conf.globalOptions and not configEnablesSkipParent(conf, cache, pd / cfg):

[ringabout]

Okay, if skipParentCfg is only necessary for cfg files. Perhaps a warning or something is needed if skipParentCfg is used in the .nims files

[Graveflo]

not a bad idea, but I don't really care about that. I believe you can push to this branch if you want since you are a maintainer.

[arnetheduck]

hmm .. the way nimble works, it puts a config section in config.nims - not having nims support would mean it also has to modify nim.cfg - in other words, having support for .cfg files is a good step forwards but it also makes it harder to teach and use the feature, so longer-term, .nims support is also important.

[Graveflo]

I can agree with the rationale, but the way I see it this feature solves a very specific problem. I think its relatively common to run into seeing as how both of us did, but it's still more of a "bail out" feature. Why would nimble need to use this? It's hard to imagine why this feature would be used for general purposes. The way I see it, this feature depends on how projects are nested on a specific machine, or in some cases how different entry points are nested in self contained repos (meaning this is required in a subdir of the AIO structure not the root). Self contained projects should not worry about the host machine's configuration hierarchy. It would be an impolite move to put skipParentCfg at the root of a code repo, for example.
Also, as a side note, Nim 3 is posturing to have 4 different config files with separate features on top of supporting these two legacy ones so apparently we are moving in this direction.

[arnetheduck]

in .nims files

in nims files, for ease of processing, this could also be a {.pragma.} which falls outside of the usual side-effecty processing.

Why would nimble need to use this

Nimble controls how workspaces are created, for the user - when creating the workspace, we want nimble test inside a "nested" library to work independently of the parent project configuration - therefore, when nimble injects a package into a nested workspace, it would also "stop" parent cfg configuration for that library (and adjust --path options accordingly) as part of its "install the package" setup - ie this is not something a library developer would do - instead, the package manager would be responsible for it and the skipParentCfg is the means of getting it done.

The mechanism nimble uses for this is to patch config.nims with a special section (atlas also does this) - it's not the prettiest of approaches, but it has the winner property that it's backwards-compatible with old nim releases.

[Graveflo]

Alright then. I don't use nimble or atlas so that might help clear it up for other people like me. When you say it "injects" the packages I assume this is some weird stuff that isn't solved by making a nimble template that drops the nim.cfg by default or just having one set up in the "tests" directory.

[ringabout]

It seems that the order of lexer error message is changed, not sure whether that's a side effect or not. Probably, a custom empty errorHandler can be used for lexer

[ringabout]

this comment can be kept under if hasProjectCfg:

[Araq]

Also, as a side note, Nim 3 is posturing to have 4 different config files with separate features on top of supporting these two legacy ones so apparently we are moving in this direction.

I'm more than happy to remove/change Nim 3's config system in favor of something better. There have been fruitful discussions about how the compiler should have a notion of a "package" and how a configuration should be package-wide.

We can also deprecate .nims files and add more features to the .cfg mechanism so that it reaches feature-parity in practice with NimScript. IMO Nimble should have taken Atlas's route and patch a nim.cfg file, not a Nimscript file, but that's rather easy to change. The .cfg mechanism is not so bad it needs replacement, only refinement. The NimScript mechanism however has proven to be the source of immense internal complexity.