# Nushell core team meeting 2023-02-22

## Attendees

- Reilly
- Darren
- JT
- Jakub
- Michael
- WindSoilder
- Stefan

## Agenda

- First stab at stdlib https://github.com/nushell/nushell/pull/8150
- Q: How to ship it?
- [nu-cmd-lang](https://github.com/stormasm/nushell/tree/nulangv1) update

* nu-cmd-lang
* nu-cmd-shell
* nu-cmd-extra
-
- ported over code post release last evening and its all working [except for the tests]
- includes core_commands, env, shells, system and viewers
- number of commands is 68
- number of dependencies is 250 crates
- now need to move tests around so that all of the tests pass

### Details
Pick one of the following lines of code to drive everything in src/main.rs

use nu_cmd_lang::create_default_context;
or
use nu_command::create_default_context;

Step 1 will be to leave nu_command crate name alone until everything has been
running and people in the community have tested the code for awhile
and then do the global search and replace from nu_command to nu_cmd_shell later

- Alias rework (https://github.com/nushell/nushell/pull/8123), proposal:
- 0.77: Add `new-alias` to test, fix stack overflow of command calling itself (to enable `alias ls = (ls | sort-by type name -i)` pattern as command)
- 0.78: Remove `alias`, rename `new-alias` to `alias`
- Passing flags through commands (see examples below)
- We need to skip shebangs: https://github.com/nushell/nushell/issues/8031. Two ways to do it:
1. Look at the first line and skip it if it starts with `#!`: https://github.com/nushell/nushell/pull/8101
2. All comments starting with `#!` would be skipped by the lexer (i.e., not appear in help messages)
- we'd have an equivalent of Rust's // vs. /// then

# Discussed Topics

## Standard lib

how to ship it?

- embedded in the code, create in the config folder?-
- embedding sounds good
- `include_str!`
- would have to be sourced first to be available in `env.nu`/`config.nu`
- or is there anything a standard library would reasonably depend on from your env
- how would this affect startup time if it is parsed everytime

Strict guidelines

- we don't want to create nu_scripts 2.0

Test framework for nu

- how should test discovery work
- How would this work in the REPL
- Reloading when updating the function under test interactively?
- related to Jakub's package manager work!
- backtrace support?
- callstack?
- do we have information in `nu.scope`
- great for TDD and also possibly for the infinite recursion issues

## Cratification

- 68 commands in `nu-cmd-lang`
- minimal viewers and `help` as well to get started
- ~250 crates to build
- should include the relevant fundamental filters
- avoid dependencies as much as possible
- should be agnostic to the metadata crimes of `ls`
- JT: hot take `open` is a super basic command
- dirty for getting it going
- no necessity for MVP
- are viewers more `shell` specific
- shell for the environment and system stuff that is shell use specific
- `nu-table` or `jt-table` with the base distro?
- on non shell platforms you need different viewers anyways
- `nu-cmd-shell`
- filesystem
- string
- ansi
- nana thoughts
- nu-cmd-lang + `open` + some cool data commands + viewers for the interactive
- don't bother with shell crimes for now
- tests need to pass then we can ship the cratification!

## Alias rework

can we make `alias` just a short hand to define a custom command that executes the long form

works fine for basic alias
similar logic for external wrapping reused

Get's rid of the bug prone span manipulation when translating back and forth in code and completion

currently `new-alias` for the next release
if nothing pokes out we can replace the old `alias`
Alternative `old-alias` as this would force users to test it (seems to be the vote)

Disadvantages:
- potential performance hit; likely only at defintion time
- (suggesting making custom commands would have the same hit)
- subexpressions can not be turned into aliases anymore
- use a custom command/closure instead
- recursion problem that needs to be addressed

Additional flags:
- custom commands currently don't support passing flags
- alias in the new style would be a good motivation to move there

## Passing flags through command

def inner[--foo, --bar] {
    if $foo { ... }
    if $bar { ... }
}

### Current situation

def outer[--foo, --bar] {
    if $foo and $bar {
        inner --foo --bar
    if $foo and (not $bar) {
        inner --foo
    } else if (not $foo) and $bar {
        inner --bar
    } else {
        inner 
    }
}

### Function call syntax

def outer[--foo, --bar] {
    inner($foo, $bar)
    # same as
    inner(foo: $foo, bar: $bar)
}

Disadvantage: Two command call syntaxes

### Using --flag= syntax

def outer[--foo, --bar] {
    inner --foo=$foo --bar=$bar
}

Disadvantage: No short-form syntax

### Runtime flags / Flags as data (???)

def outer[..-flags] {
    inner $flags
}

Disadvantage: We lose signature information (`help outer`) and static type checking.

# PR's

- shebang currently get's added as documentation
- should not be added
- either we except the start of file shebang
- alternatively `//` vs `///` with `#!` and `#` for non-documented and documented