---
# System prepended metadata

title: Nushell core team meeting 2025-07-16

---

# Nushell core team meeting 2025-07-16
## Attendees
- Darren
- Michael
- Bahex
- Rose
- Douglas
- Stefan
- Jack
- Yash
- 

## Agenda
- [x] `$NU_VENDOR_LIB_DIRS`:
  Third party integrators should prefer to have integration code packaged along with their software, rather than having users generate it in shell init
  > zoxide does this for completions with `extern` definitions

  But if everyone places their code in vendor autoloads:
  - increasingly slower shell startup as nushell has to parse more and more code
  - users having to override unwanted settings: they might prefer their own custom solutions rather than vendor provided code

  `$NU_VENDOR_LIB_DIRS` would be where modules that just needs to be available would be placed. Like `$nu.vendor-autoload-dirs`, generated from `XDG_DATA_DIRS`
  | Autoload                                 | Modules                                 |
  |------------------------------------------|-----------------------------------------|
  | `/usr/share/nushell/vendor/autoload`     | `/usr/share/nushell/vendor/modules`     |
  | `~/.local/share/nushell/vendor/autoload` | `~/.local/share/nushell/vendor/modules` |

  This way we avoid startup slowdown and actually activating the code is up to the user.

  > [!NOTE]
  > We don't actually need to have a separate `$NU_VENDOR_LIB_DIRS` variable.
  > Just add `$nu.vendor-lib-dirs` _and_ include them in `$NU_LIB_DIRS` by default.
  > User can choose to override `$NU_LIB_DIRS` to add or remove them as they want.

  > [!NOTE]
  > Let's have a documentation page on nushell.sh for third party integrators

- [ ] **Tracking Issues for Experimental Options**
  Stefan mentioned in the PR about more info on experimental options that we maybe should have tracking issues besides them https://github.com/nushell/nushell/pull/16142#discussion_r2198479260

  We should come up with how we want to deal with experimental options and define some documentation for that
- [ ] 

## Discussed Topics

### Proposal for `$env.NU_VENDOR_LIB_DIRS`
- Use case: user explicitly `use`s module which was provided by a third party integration
- Douglas: could this just be covered by explicit addition to `NU_LIB_DIRS`
- Rose: explicit `use` vs auto-import for parsing efficiency
#### Challenges for the requirements
- different opinionated package management solutions
    - e.g. nix vs apt vs cargo install vs ...
- ease of setup vs. what gets autoloaded/dumped/parsed -> perf/setup flexibility
- Rose: shared config (e.g. in VCS) operating with integrations that are on one machine provided as user level and on the other as a system level package.
#### example `carapace`
rundown by rose:
user level (handled by `carapace init`):
- create vendor/modules/carapace/mod.nu
- create vendor/modules/autoload/carapace.nu (contains `use carapace`)

package level:
- create vendor/modules/carapace/mod.nu
- user manually adds `use carapace` to their config

#### can we still have the `$tool init` pattern with nicely arranged modules

### Experimental options / Tracking issues
- replace `PR` field with tracking issue
- add to CONTRIBUTING.md how we want to deal with experimental options including creating tracking issues
- template for tracking issue
