Nushell core team meeting 2023-03-22

Attendees

  • Reilly
  • Darren
  • Michael
  • JT
  • Antoine
  • Stefan

Agenda

Discussed Topics

  • Codeowner file

    • People are OK with it
    • Darren: we might need to enable "branch protection rules" as suggested by hofer-julian
    • wait maybe we misunderstood the codeowner file; sounds like it's more about review than permissions
    • Still OK with it

  • JT's let/let-env PR

    • Sounds good to everyone

  • match

    • JT has been inspired by the let/assignment work

  • std.nu

    • integrate sooner rather than later
    • include in the source code
    • define the prelude (part of the std library that will be used automatically)
    • nu-utils as a location is unfortunate (resolution of a dependency hell for the configs)
      • move to a better place when time is available and the integration works.
    • PRs to remove the reimplemented commands from the rust source
      • already ready!
      • helps with the cratification
    • challenging: x-platform testing
      • std lib tests failing on mac
      • path expansion of symlinks
      • (is there a breakage in the rust code?)
      • what is going on in paths ... | path expand | path expand
      • partial solution of the test suite in https://github.com/nushell/nushell/pull/8552
      • shoud path join auto-expand?
      • ~ expansion in strings might also be an additional source of problems here
        • fun of the type directed parser: only path that can expand in commands that expect a path
        • maybe remaining areas that we treat inconsistently
      • off-topic rant: ` and " still are a mess around executables with weird paths

  • postpone talking about alias evolution for Jakub

  • rust version bump

    • distro packagers hate us if we are too far ahead
    • two options for how we enforce the version
      • ci
      • rust-toolchain.toml
    • might be worth setting up a cron-ci job with the stable or beta channel

  • question mark operator for short-circuiting cell path access

  • forced || closure parameter list

    • it clarifies between closure and block
    • will cause a breaking change for basically everybodies config
    • how does it feel in practice?
      • tedious to add in your existing codebase
      • if you know that there is a difference between closure and blocks you are probably more sympathetic.
      • is it really cleaner?
      • || is not the most beautiful thing?

PR's

Select a repo