owned this note   changed a year ago  
Published Linked with GitHub

Nushell core team meeting 2024-05-01

Attendees

  • Jack
  • Ian
  • Darren
  • Antoine
  • Andy
  • Devyn
  • Michael
  • Andrés
  • Wind

Agenda

  • Release update. Do we need a patch release?
  • $.major, $.minor and $.patch in version? => better to use a plugin such as nu_plugin_semver?
  • serializing closures in NUON? see #design-discussion
  • Raw string syntax #9956
  • Move plugins to separate repos?

Discussed Topics

Sem ver in version

  • Limited use case, nushell can easily parse the full version string.
  • May be slightly more convenient, e.g. for tools like atuin.

Serializing closures in NUON?

Cell paths? Closures? Should we serialize them?

  • What's the future of NUON? Should this be a portable format, or should it be something useful for Nushell primarily?
    • We don't have a spec. We just use the nu parser. Should we standardize and create a parser specifically for it?
    • Jakub: maybe people would want to implement NUON in another language
    • Want Sophia's input. Seems like the original goal is that it's more concise and supports more data types
    • Tables are a major plus, compared to JSON? (also comments, trailing commas, dates, filesizes, durations, binary data, etc.)
    • Compared to JSON5? What do we offer over that
    • If NUON is going to grow in the wild, we need a spec. Up to whoever wants to start that.

Raw string syntax

  • Ready to land, but
  • What should the syntax look like? r# like Rust?
  • Rust also even supports r##"string"##, with any number of balanced sigils. Even zero
  • Do we like #? It's our comment symbol
  • Maybe we should not allow double quotes? Usually double quotes means escapes are allowed
  • Sounds like # > @, and ! is not well liked
  • Go with r#''# for now
  • Maybe heredocs later?

Move plugins to separate repos

  • Would be nice eventually, but might not be worth it now:
  • CI concerns (which PR broke the plugin)
    • nightly build with main?
    • workflow build of out-of-repo plugins with each nushell PR?
    • PRs often break plugins due to API changes
  • Packaging concerns
    • right now we distribute them together with nushell
    • nupm is not mature enough yet for distributing the core plugins but hopefully someday it is
  • In the future maybe plugins in their own repo could work similarly to the way we handle Reedline in its own repo ?
  • Again the main issue here for now and the reason we are not going to move plugins to their own repo is because we need a way for nushell developers to know immediately that their code is breaking the plugins so they can fix the plugin code or their code prior to their PR landing.

Issues

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
the issues which needs-core-team-attention

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Note
to list all the PRs currently opened in nushell/nushell:

gh pr list --json url,number,author,title
| from json
| each {|i|
    $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
}
| reverse
| to text
Select a repo