Auto-source config files in `$nu.default-config-dir/conf.d` and modules from `$nu.default-config-dir/modules.d`

[NotTheDr01ds]

Auto-source config files in `$nu.default-config-dir/conf.d` and modules from `$nu.default-config-dir/modules.d`

[fdncred]

We've talked about this recently in some other issue that I can't find. The synopsis, as I remember it, was to have something like NU_LIB_DIRS where script files/modules could be stored and if they are present get sourced on startup. I probably won't support folder named conf.d and modules.d because they're way to Linux-y. However, if there was something like NU_AUTO_SOURCE, and it was a list of folders, you could name them anything you want.

[fdncred]

Is there an ETA on this? This is one of the most important thing missing for me to switch to nushell. Managing config files in 3rd party tools (part of dotfiles) would be much more easy.

It's just waiting on someone to implement it.

[ADIX7]

Is there an ETA on this? This is one of the most important thing missing for me to switch to nushell. Managing config files in 3rd party tools (part of dotfiles) would be much more easy.

[NotTheDr01ds]

@ADIX7 I'm not a Rust developer (yet, but I'd love to learn), but it seems to me to be a relatively easy implementation. Might be a "Good First Issue" for someone to work on, but I'll let a Nu team member make that determination.

[NotTheDr01ds]

And I came back over to add that this isn't only for third-party modules.

It's far more easy to just <nano/vi/edit/code> ~/.config/nushell/conf.d/my_function.nu and edit away than it is to find the function/custom command declaration in a monolithic config.nu, even with the best of IDE/editors.

[NotTheDr01ds]

Throwing out a ... maybe ... include subdirectories of conf.d/modules.d automatically as well? This would allow you to git clone a module/script directly into the directory ...

The structure of the repo would have to be "just right" though, or would need some convention to specify what to load (and what not to).

Which reminds me, this ultimately goes to a "convention over configuration" mindset, I believe.

[NotTheDr01ds]

Is there an ETA on this? This is one of the most important thing missing for me to switch to nushell. Managing config files in 3rd party tools (part of dotfiles) would be much more easy.

It's just waiting on someone to implement it.

Good first issue for someone, or are there nuances I'm not anticipating?

[fdncred]

Good first issue for someone, or are there nuances I'm not anticipating?

Yes, there will be nuances like:

1. when should they be loaded, before x file, after y file
2. when should they be loaded, with x parameter or with y parameter
3. should all of these be merged into the root overlay or should it be a new one
4. probably other concerns here too

[NotTheDr01ds]

@fdncred Fair enough

I'll try to experiment with various flavors of this (via hard-coded source and use statements in config.nu for now) to see if I can flesh out the recommended implementation.

For #1, at least, I recommend loading after all default configs are processed (env.nu, config.nu, and login.nu - Is that the complete set?). This allows the conf.d files to act as overrides on any "default" or pre-existing settings. Again, that's the way other conf.d implementations tend to go.

The main question on item 1, though, that I'm not sure about is how to choose the ordering of modules vs. source'd files. Again, I'll experiment.

[fdncred]

I recommend loading after all default configs are processed

i agree

number 2 is about nu --parameters e.g. should it be loaded with nu -c, what about nu -c -l, what about nu --stdin, what about....

that I'm not sure about is how to choose the ordering of modules vs. source'd files.

One thing about ordering, iirc, some linux types do 1.filename 2.filename 3.filename, etc. i'm not sure we need to do that or not and i'm also not sure how that plays with source, source-env, use, overlay, overlay use, etc

[lpnh]

If I've understood correctly, this sounds like a great feature to be implemented!

Could this be related to the following? #5682 #8214