# Nushell core team meeting 2023-03-15

## Attendees

- Darren
- Michael
- JT
- Jakub
- Reilly
- Stefan
- Andres

## Agenda

- stdlib
- distribution
- cratification update:
- [nu-cmd-lang](https://github.com/stormasm/nu_cmd_lang77) is working great as a standalone crate both with and without the table viewer and NOTHING else
- nu-cmd-lang only pulls in 255 crates and nushell builds super fast
- the binary starts up fast especially without config info
- I believe I have a nice working version of the nu! macro that does not pull in config files
- next step is to see how it works with nu-cmd-lang tests and best location for the tests...
- tests of http commands?
- We have ~900+ lines of untested code in http commands
- parsing changes
- Impact
- package manager exploration demo https://github.com/kubouch/nuun
- suggested standard package layout
- related to stdlib distribution

# Discussed Topics

## Standard library

Amtoine has started a PR wave with the stdlib effort

- 19 PRs already

A lot of commands can easily be implemented in nu

JT spun up `help` in half an hour
Amtoine wrote the banner in a more readable form

Increases the contribution accessibility
Amtoine is shepherding the effort

Goals:
- both encourage new contributors
- establish best practices for nu code for others to follow
Make sure we can balance that

### Distribution way for std lib

1) embed in the binary
2) embed in the binary but write out to FS and read it from there
3) embed in the binary and write out but use only the baked version
4) through the package manager to be decided on

Versioning could become a pain

Config has the same issue already (but there are expected user changes here)

Is there a way to get rich structured versioning?
(for the std lib we can add a comment)
but with the config it can break easily.

Rust ships `std` as a "crate" with `Cargo.toml`

#### Suggestion
Start with the most conservative version for `std` first > option 1 ship baked in.
Go beyond the single file include as it becomes necessary but solve this problem as it is needed

Already three files
- `std.nu`
- tests
- dirs (`shells`/`n`/`p` replacement)

## Module directory

Kubouch has been working on the directory import for modules
Could be ready for next release

Q: Symbol resolution order with multiple files

two steps:

- define a module (module command)
- should be order independent
- import defs from the module (use command)
- export env is a special case as the order matters

Reexport already supported for defs but not submodules

Solution: `mod.nu`

### Defining a prelude

Stuff you can directly use with out `use` ing specifically

What part of the standard library should be reexported from the std library effort.

e.g. `help` in its reimplementation

don't start every nu session with

`use nu std.nu *` or else

module std.nu
use std prelude *

Could be an overlay (and you could rip it out if you don't want it)

## Cratification

Michael started trying to build a nu on top of the now released `nu-cmd-lang`: https://github.com/stormasm/nu_cmd_lang77

Currently all the tests tend to use a full nu build with a config.

The default config is shell oriented and can thus not be directly used for testing stuff only in `nu-cmd-lang`

`env.nu` might be loaded in the script or `-c` mode (check what is loaded from the user and from the defaults)

Only few commands need the config state but we shouldn't regress on the behavior

Question ?
Does the nu! macro in concert with the -c flag
pull in both config files ?
1 of 2 config files ?
or no config files ?
if its just 1 config file which one is it ?
remember the nu! macro runs the nushell binary that has been built prior

## Test restructuring

sub Crates depend on the full build

Also we launch a full nu instance for minimal tests that wouldn't need the whole environment

Could we move some tests on the evaluator directly for the parser and core language tests as they shouldn't mess with the env anyways!
Should improve test performance
Isolates the `nu-cmd-lang` behavior from config.

For `nu!` tests of `nu-cmd-lang` we need to be aware of the config

### http commands

900 lines of untested in the initial refactor PR but we now have some tests with `mockito` thanks to @jaudiger
Thanks!

## Parsing changes

JT wants to slay the dragon (book)

Bob and JT discussed a bit in the direction of more traditional parsing

can we succeed or fail earlier to avoid parsing demons (like the record/closure confusion)

leading characters become more important to narrow the parse

e.g. all numeric values starting with numbers

pulls us away from shapes

Tradeoffs:

- 7z
- would require escaping

Benefits:
- much easier to react to failures with suggestions
- adding a units of measure package wouldn't be a breaking change

Alternatives:

Cheat for 7z

Lazily materialize the parse error at name resolution time (would probably suck for LSP)

## Packaging demo

`nuun`

subcommands
`init`
`install`
`new`
`overlay`
`overlay new`

`.nuun` file

project structure:
`.nu` file(s)
(the guy who wrote it added a shebang)
`.nuon` as a manifest

either scripts as binaries or larger projects

Also includes an environment management level through overlays

foreign packages can be loaded into the environment through small build scripts

Pain point right now: tests (do we need an eval)

## PR's