config.nims should apply to subdirectories recursively, like nim.cfg does

[timotheecour]

it's kind of useless to have config.nims not apply recursively (since it can always be overridden in subdirectories as needed). Also, making it recursively apply to subdirectories would be less surprising and consistent with behavior of nim.cfg (and gitconfig, gitignore, etc...)

(see also https://forum.nim-lang.org/t/4019)

[andreaferretti]

Can you document what the structure of your project is? In general, config.nims is applied to the whole project (which means to subdirectories as well), as long as you import the files in your subdirectory from your main file. Configuration is per project, not per file

[timotheecour]

@andreaferretti

Can you document what the structure of your project is?

exactly as described here: https://forum.nim-lang.org/t/4019#25026, reproduced here:

subdir/
    test.nim
toplevel.nim
config.nims

as long as you import the files in your subdirectory from your main file

In my use case, I want to be able to run these and have ./config.nims apply to anything under ./ (just was nim.cfg would) but this isn't the case:

nim c toplevel.nim # will use config.nims
nim c subdir/test.nim # BUG: will NOT use config.nims

This makes it impossible to use nimscript in place of nim.cfg files ; eg use case: having a ~/.config/config.nims to replace my ~/.config/nim.cfg ; currently this would not work.

[Araq]

I dislike this "let's look in all parent directories for a config" behaviour of the old nim.cfg files which is why I didn't replicate it in the newer Nimscript system. It's easy enough to have a config.nims that include's the parent's config.nims.

That said, I don't have a strong opinion on it, so feel free to overvote me on this one.

[timotheecour]

I actually really liked that recursive behavior, it's standard and the least surprising (cf: gitconfig, gitignore, nim.cfg etc ; happy to show more examples)

It's easy enough to have a config.nims that include's the parent's config.nims.

I don't see how that would be practical or possible ; say I have a top-level ~/config.nims where I put all my preferred settings and customizations (hints, etc) everytime I use a third party project Foo (eg via nimble install), I'd have to add a Foo/config.nims in that project with include "/Users/bob/.config/config.nims" at the top (and modify each config.nims in that project)

[Araq]

say I have a top-level ~/config.nims where I put all my preferred settings and customizations (hints, etc)

That's the user specific config, that's already specialized and always processed anyway.

[timotheecour]

@Araq

That's the user specific config, that's already specialized and always processed anyway.

that doesn't seem to be the case: ~/.config/config.nims isn't used below:

cat ~/.config/config.nims
echo "in top level config.nims"

cat bugs/t35_nims.nim
echo "bar"

nim c -o:app -r bugs/t35_nims.nim
Hint: used config file '/Users/timothee/.choosenim/toolchains/nim-#devel/config/nim.cfg' [Conf]
Hint: used config file '/Users/timothee/git_clone/foo/nim.cfg' [Conf]
CC: timn_t35_nims
CC: stdlib_system
Hint: operation successful (12048 lines compiled; 0.580 sec total; 16.285MiB peakmem; Debug Build) [SuccessX]
bar

[timotheecour]

that doesn't seem to be the case: ~/.config/config.nims isn't used below:

=> just sent out PR https://github.com/nim-lang/Nim/pull/8233 to address this point

[andreaferretti]

everytime I use a third party project Foo (eg via nimble install), I'd have to add a Foo/config.nims...

Why do you think this is the case? If your project depends on a third party lib, you can just declare the dependency in a nimble file (which allows nimscript), and then whatever flags you put in that file will be applied across the whole project, including your dependencies.

Alternatively, if you don't want a nimble file for some reason, you can nimble install your dependency. Then, when a nim module of yours uses that dependency, compiling your module will just take the source code from your dependency, hence the configuration for your project will be applied.