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 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