Nushell core team meeting 2023-02-01

Attendees

  • Andres
  • Darren
  • JT
  • Jakub
  • WindSoilder
  • Stefan
  • Michael
  • BobHy

Agenda

  • Release 0.75
    • Post release comments
  • Unintended consequence of auto-trimming (see example below)
  • --ignore semantics and the do + complete weirdness.
  • Proposal: Remove overloading until we have a complete design ready
    • requires dataframes considerations: could be moved to a module which can be applied as overlay on-demand
      • which leads to: Should plugins be modules?

Discussed Topics

Release 0.75

Smooth sailing apart from winget

release_pkg.nu script is misbehaving

Darren reached out to Justin who wrote this script

Auto trimming of quotes in arguments to nu

Auto-trimming issue:

> open foo.nu
def main [x] { print $x }

> nu foo.nu '(^ls)'
...prints native ls output

Danger zone: regular expressions look like subexpressions (that start by executing commands)
e.g. (hello|world)

BobHy: working on the error handling of syntax errors through the parser.
Bare string handling happens in many different places and tracking down errors there is really hard.

Also challenges in assigning types vs allowing numbers in command names (or possibly bare words) e.g. 7z

Current state: we have type directed parsing with a large range of edge cases that have to be tracked through multiple stages (also duplication in the typechecking)

Big Problem: we are very context-sensitive and creating grammars and syntax plugins is hard or near impossible to get right.

Can we be more local to really constrain us in a helpful way.

Going back to the issue:

can we make the parser dumber in such situations? Ensure it remains a string (with quotes or maybe as an explicit nu command that knowns about types)

We are probably never able to fully solve the risk that a non-nu shell will strip quotes.

Can we declare best practices that are easy to remember for users.
And make it as seemless as possible from nushell.

Jakub can we filter based on what is currently "constevalable" i.e. basically literals

Big bomb EVAL

See discord discussion with broot (also all the environment managers :P)

https://discord.com/channels/601130461678272522/759901889978040331/1070257365783433217

Different behavior between in the REPL and inside of scripts (REPL effectively allows modification of engine state parts that are considered constant in a script)

Jakub raises the pitchforks against eval

  • Module systems/overlays added more comfort
  • Not having eval is great for IDE experience
  • SECURITY

Can we have eval lite?

do/complete complications

problem our pipelinedata is not fully compatible with the existing POSIX model of STDOUT/STDERR and exit codes for error handling

Piping to complete is weird magic

do has ignore options for "all errors"/"program errors (external)"/"shell errors"

try catch is still around

Shell/scripting language balance

https://github.com/nushell/nushell/discussions/7899#discussioncomment-4843817

Test: does a change make writing a one-liner easier or harder

  • is it not painful to write
  • is it going with a flow
  • will it compose effortless

surrounding a pipeline stage with try/catch after you realize something could fail, feels fingertwisting

Jakub: can we have some syntax constructs that don't require wrapping with {} all the time

JT: keep the spirit of the ls | where size > 10MB base example

PR's

Select a repo