# 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