RFC: Redesign config structure #5
Conversation
| vpn_client = "/opt/vpn_client/bin" | ||
| cargo = "/home/leo/.cargo" | ||
| ``` | ||
| 4. Some settings are not put inside a table `[...]`. Those could at least be grouped under `[general]`. |
There was a problem hiding this comment.
yes, agreed about [general]. I'm definitely for more orgainization.
| - Add `package unload` => Unload a config/package | ||
| - Add `package init (path)` (Initialize package structure under path, so users don't have to look it up all the time) | ||
| - Allow passing of --local to `config rm <key>` (Remove key from last loaded local config), `config set/set_into <key>` (Set key/value into last loaded local config), `package list` (Only show local configs). | ||
|
|
There was a problem hiding this comment.
my one wish for a config command set update is that we move to toml_edit so that comments are respected and maintained. today, with our current config setting tools, comments are removed.
There was a problem hiding this comment.
I agree. The current config code makes a lot of assumption. It will need some substantial rework, especially after accepting this RFC.
|
Generally speaking, i like this rfc. I think there's a lot of good points in it. i've commented on a few details. Thanks @LhKipp!! |
| 5. With `.nu-env` and the "global" config under `$HOME/.config/nu/config.toml` being merged, we can think of `autoenv` as a local config (a config local to a directory). Therefore we could rename `.nu-env` to `.nu/config.toml`. (We may need to adapt the `autoenv` commands accordingly) | ||
| - Rename `autoenv trust` to `package trust` (see 9) | ||
| - Rename `autoenv untrust` to `package untrust` (see 9) | ||
| 6. We have `startup` and `on_exit`. We could rename `startup` to `on_enter` (Better naming, better consistency (`enter`/`exit` command)). |
There was a problem hiding this comment.
We can also think about adding a on_enter.nu and on_exit.nu file right next to the config.toml. on_enter and on_exit config values don't scale past 1 line of code. Files (I think) would suit most users better.
There was a problem hiding this comment.
This reminds me, I've been looking at the fish shell source code recently. I noticed that most, if not all, of their built in commands have cpp code but they also all have *.fish commands too. i.e. there's cd an cd.fish. I was thinking that this could be an approach we take with nushell in our stdlib.
There was a problem hiding this comment.
Sounds cool. Is it something we need to consider when redesigning the config (and how configs should work)?
There was a problem hiding this comment.
I think it's probably a broader conversation about stdlib and built-in commands in general. so, we can probably drop the discussion about it since it's not specifically related to config.
There was a problem hiding this comment.
Good. But I generally agree with your opinion. It would also allow us to prototype stuff faster :).
|
Another thing we should consider, if we want a package system: How are default values implemented? One approach could be: Allow a file
set write_to = $(config get where_should_my_package_write_to)
if write_to == "" {
write_to = $HOME/default_path
} But instead they can write code like: # There exists a default value for each config item, so we don't have to check
set write_to = _$(config get where_should_my_package_write_to) |
|
Another thing, that could be considered (but doesn't have priority imo), would be to validate configurations before loading them. |
|
I'm guessing packaging is beyond a 1.0 scope but it would be good to get @jonathandturner 's and @andrasio 's take on this. |
I don't think its that hard and I think its important. Packaging solves the problem: How can users share code / config? I think a good answer is something that user already want. Currently users can only share their scripts on Discord or by contributing to nushell/nu_scripts (Or by contributing them as commands to nushell directly)... All options are sub-optimal from my pov. |
No description provided.