Nushell support

[jneem]

This is a continuation of #6330, adding nushell support.

As in #6330, nushell support for opam env works via json (so the command to populate the environment is load-env (opam env | to json)).

This also adds shell config support, but doesn't yet setup any hooks.

[kit-ty-kate]

the default config location seems to be a bit more complicated than that. In particular, the default $HOME/.config/... is only true on Linux, not macOS or Windows (see https://www.nushell.sh/book/configuration.html#configuration-overview)

[jneem]

I took a stab at improving it, but it's untested on macOS and Windows. For background, nushell uses the dirs crate as a fallback if XDG_CONFIG_HOME is unset. It's behaviour is documented here. On windows, it actually uses win32 bindings, but some random googling suggested that maybe the APPDATA env var would also work...

[kit-ty-kate]

this seems possible using https://www.nushell.sh/book/hooks.html#pre-execution-hooks

[jneem]

Not yet done, and I've run out of time for today. I'll re-request a review when it's ready for another look.

[jneem]

Ok, done now.

[kit-ty-kate]

it feels like it could be shorten to

Suggested change

	Printf.sprintf "const source_path = if ('%s' | path exists) { '%s' } else { null }\nsource $source_path\n" fname fname
	Printf.sprintf "if ('%s' | path exists) { source '%s' }\n" fname fname

[jneem]

It feels like it, but no... for reasons I don't really understand, the source "dep.nu" in

if ("dep.nu" | path exists) { source "dep.nu" }

is evaluated unconditionally at parse time, while the "if" condition is delayed to run time. But, if you write it as

const source_path = if ("dep.nu" | path exists) { "dep.nu"}
source $source_path

then the "if" condition is promoted to parse time. It does look like I can remove the "else null" part, though.

[kit-ty-kate]

ah thanks, this is explained in https://www.nushell.sh/book/thinking_in_nu.html#think-of-nushell-as-a-compiled-language

[kit-ty-kate]

oops i hit enter a bit too fast. Thanks a lot for your contribution, would you have some spare time to look at the issues highlighted above. I think that once they are all fixed this should probably be in a mergeable state

[jneem]

Thanks for the fast response! I should be able to do another iteration over the weekend.

[rjbou]

Thanks for the (follow-up) PR. We discussed it in dev meeting: we need to take into account the fact that nushell is prone to change:

• make sure that the added commands are part of the baseline of most of versions
• add a minimal version check when enabled/selected
• add a note that informs users that their specific versions could not be supported, and a hint on how to disable/fallback on another shell.
• update (at least) tests/reftests/init-scripts.unix.test with the new nushell files

Otherwise, the current content is quite ok (quite bc it needs to be reviewed).

[jneem]

make sure that the added commands are part of the baseline of most of versions

Do you have any guidance for how to determine "most" here? Nushell maintains a packaging status table, but it isn't completely obvious to me where to draw the line. For example, I often use Debian's packaged version to determine the oldest version that's worth supporting, but apparently Debian doesn't package nushell...

[kit-ty-kate]

That's a good question, ideally from that table, i would say "replace debian by <fairly used distribution with the oldest version of nushell>", which in this case is Fedora (0.99.1).

Sadly in this case, it probably complicates things a bit too much, because source null apparently wasn't a thing before 0.102: https://www.nushell.sh/blog/2025-02-04-nushell_0_102_0.html#source-null-use-null-toc

So if that's not possible, i'd say probably 0.104 (latest nushell version in Alpine since 3.22) is a good starting point.

[jneem]

I spent some time trying to add a minimal version check to the autoload script, with the goal of producing an actionable error when invoked with an old nu. I didn't succeed, though, because the error is raised during parse time. For example, sourcing the script

if (version | get major) == 0 and (version | get minor) < 102 {
  return
}

const s = if ("dep.nu" | path exists) { "dep.nu" }
source $s

with nu 0.99 gives the error

Error: nu::parser::type_mismatch

  × Type mismatch.
   ╭─[/home/<me>/test.nu:6:8]
 5 │ const s = if ("dep.nu" | path exists) { "dep.nu" }
 6 │ source $s
   ·        ─┬
   ·         ╰── expected string, found nothing
   ╰────

The version guard has no effect, because the error occurs before anything is run. I tried a few hacks to get the version guard to run at parse time, but without success (in 0.99, not even the get command can run at parse time -- that appears to have changed sometime between 0.99 and 0.111).

So maybe the best course of action is to hold off on this until 0.102 is old enough that we can assume everyone uses it. In the meantime, direnv and eval $(opam env) give a pretty reasonable nushell-compatible setup.

[kit-ty-kate]

what about simply parsing nu --version in OpamClient.init_checks? (you just need to pass shell to it).

The check would be done only once at init time but i don't expect people to start downgrading their version of nushell, and if so i think they would probably expect something to break.