owned this note changed 7 months ago
Published Linked with GitHub

Nushell core team meeting 2024-08-21

Attendees

  • Jack
  • Darren
  • Michael
  • Yash
  • NotTheDroids
  • Stefan
  • Devyn
  • Levertion
  • Andy

Agenda

  • Release rollup
    • 13662 Justin identified a record parsing issue (not sure if it's new)
  • PR Input (not super important, just need input)
    • Looking for suggestions for better function names for 13633
    • IntoValue/FromValue 13641
    • FromValue attribute 13647
    • Record values with colons 13413
    • Set current dir at startup 12953 - is this worth one of us fixing the conflicts?
  • testing
    • being "adverserial" to the implementation
    • make it easier to add more cases
    • infra improvements

Discussed Topics

Release 0.97

  • Ultra quick fix of the .. issue (thanks Devyn and Yash)
  • 13633 could also be a potentially older issue
    • This is seems to be down to quoting and unquoting in processing for external and then in the nu binary argument parsing
  • issue reacting to the new error message for bare word in assignment rhs
    • maybe rephrase for "use quotes, or if you want to execute caret"
    • doesn't warrant a point release

PR party

YizhePKU cwd change

  • the reedline integration needs explicit work
  • could uncover some additional bugs
  • author AWOL, devyn could take care

Piepmatz's derive macro magic

  • bytes dependency should be fine
  • Allow plugin authors to use a serde-like API

consolidating the naming of the flags and args accross the codebaase

  • named flag confusion
    • args/positional
  • Call(Ext)

Testing

  • Bug fixes without regression tests
  • PRs often don't have associated tests
  • be more biased towards tests
  • let's set up a meeting to discuss a new testing approach (builder?)
  • make tests easier
    • too many different ways to run tests
    • plenty of locations
  • (test modalities, tests with config/without, isolation/sandboxing etc.)

complicated config loading matrix

  • Darren's gist
  • very relevant for testing to make sure we have the behavior users will see (or be tolerant to the user test systems)
  • potential divergence between Rust internal defaults and the default config
  • not having to parse is much faster (also something desirable for tests)

example tests

  • are doctests (not for edgecase testing of command behavior)
  • we have too many None in result as running has indeterminate output/is dangerous
    • some could just be parsed if they are dangerous to run
    • test for pure success instead of fixed result
Select a repo