As discussed in the thread at #2346 (comment), the installer may resolve a different Nushell vendor autoload directory from the session that launched it. This is a follow-up and does not block the current directory layout work.
The installer discovers the user-local vendor autoload directory by starting a new Nushell process and reading $nu.vendor-autoload-dirs:
nu -c '$nu.vendor-autoload-dirs | reverse | each {|dir| $dir } | str join (char nl)'Nushell resolves XDG_CONFIG_HOME and XDG_DATA_HOME at startup. Its documentation states that these variables must be set before Nushell is launched:
https://www.nushell.sh/book/configuration.html#changing-default-directories
If Nushell starts without XDG_DATA_HOME in its parent environment and config.nu later sets it to /custom/data, the current session continues using the autoload directories that were resolved before config.nu was loaded. However, the installer inherits the updated environment and starts a new nu -c process, which selects /custom/data/nushell/vendor/autoload.
A new top-level Nushell started from a parent where XDG_DATA_HOME is still unset will again resolve its original autoload directory before loading config.nu. As a result, the installer may report that Nushell was configured successfully while normal new sessions do not load the generated vite-plus.nu.
Although setting these variables in config.nu is outside Nushell’s documented startup model, leaving XDG_DATA_HOME unset is common, and managing environment variables in config.nu is a natural choice for users.
As a follow-up, we should confirm this behavior with an integration test and decide whether to handle the mismatch, warn about it, or document that XDG startup variables must be provided by Nushell’s parent process.
I can take responsibility for this task after the current PR is merged.
As discussed in the thread at #2346 (comment), the installer may resolve a different Nushell vendor autoload directory from the session that launched it. This is a follow-up and does not block the current directory layout work.
The installer discovers the user-local vendor autoload directory by starting a new Nushell process and reading
$nu.vendor-autoload-dirs:nu -c '$nu.vendor-autoload-dirs | reverse | each {|dir| $dir } | str join (char nl)'Nushell resolves
XDG_CONFIG_HOMEandXDG_DATA_HOMEat startup. Its documentation states that these variables must be set before Nushell is launched:https://www.nushell.sh/book/configuration.html#changing-default-directories
If Nushell starts without
XDG_DATA_HOMEin its parent environment andconfig.nulater sets it to/custom/data, the current session continues using the autoload directories that were resolved beforeconfig.nuwas loaded. However, the installer inherits the updated environment and starts a newnu -cprocess, which selects/custom/data/nushell/vendor/autoload.A new top-level Nushell started from a parent where
XDG_DATA_HOMEis still unset will again resolve its original autoload directory before loadingconfig.nu. As a result, the installer may report that Nushell was configured successfully while normal new sessions do not load the generatedvite-plus.nu.Although setting these variables in
config.nuis outside Nushell’s documented startup model, leavingXDG_DATA_HOMEunset is common, and managing environment variables inconfig.nuis a natural choice for users.As a follow-up, we should confirm this behavior with an integration test and decide whether to handle the mismatch, warn about it, or document that XDG startup variables must be provided by Nushell’s parent process.
I can take responsibility for this task after the current PR is merged.