owned this note   changed 2 years ago  
Published Linked with GitHub

Attendees

  • storm
  • fdncred
  • sholderbach
  • amtoine
  • kubouch
  • jt
  • andres

Agenda

  • (quick topic) CI does not behave as expected: @amtoine might need help
    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 →
    (amtoine/nushell#5)
    • clarify offline -> Stefan, Antoine
  • (quick topic) aliasing type to which to avoid confusion (#5196) => change the coloring
  • Breaking changes policy
  • What other breaking changes should we aim for in the near term?
  • $in
  • New issue labels
    • release-note-mention to highlight PRs that should be reflected in the release notes even if they are not breaking changes
    • new-command to raise awareness for PRs introducing new commands
    • TODO: strengthening and also consolidating our list of labels
  • Non-English issues on GH
    • Problem: don't contribute to the general discussion and need to be serendipidously picked up by native speaker (translatable but not searchable).
    • Outright closing them might be a bit harsh
    • Maybe only allow non-English only in "Discussions" with a language prefix or when helping out one-on-one via code-review comment threads.

Discussed Topics

Confusion on BSD with type command and relationship to nu's which

  • cross-platform issue: BSD preference colliding with type on Win
  • clarify with commenter
    • can this be resolved by personal settings
  • better highlighting for internals vs externals necessary in our theme?

Breaking changes policy

  • Darren: Deprecation vs Removal, we just remove and provide some help
  • JT: delay until it is finally removed, it would be great to also add metadata to commands (e.g. deprecated for custom commands, desire for metadata already came up with testing)
  • let's get the correct style of deprecation soon
  • institute stricter deprecation policy e.g. around 0.90
    • no yeeting commands without soft warning

Detour: Docs are in a state of a few months ago

  • commands are suggested that are already deprecated/removed
  • Q JT: how do we want to teach nushell in the future
    • Tutorial style to introduce to get productive
  • Darren: cookbook is a great way to learn for me. can we get some great real world examples
  • JT: make the cookbook more visible or interleaved in one book
  • Jakub: have a story line of an example project going through the learning book (see The Book from Rust) maybe also a good candidate for the tutor command
  • Amtoine: are we ready to invest the time with the state of the project
    • JT: the gist of nushell is pretty settled, Pipelines
    • As technical writing goal: Nu Language Guide may also serve as a specification and reference for developers
  • CI testing of the docs code samples!
    • should be doable
    • we already have some code in snippet files
    • How with triple backtick sections? is there a way to hook into VuePress?

Planned breaking changes:

Storm: moving math commands

  • Stefan: let's give it a go and if it hurts let's move highly requested ones back
  • Plugins could also become an option for mitigation

Syntax to express (table types

JT's suggestion of having look-a-like type syntax

x: [int] # list of ints
x: {y: int} # record of one field
x: [{y: int}] # table of one column

current proposal based on 1kinoti's PRs

x: list<int>
x: record<y: int>
x: table<y: int>
  • Table PR: https://github.com/nushell/nushell/pull/9613
  • Jakub: not very surprising for types
  • JT: maybe the types should be capitalized 
    ​​​​x: List<int>
​​​​x: Record<y: int>
​​​​x: Table<y: int>
    • containers capital, primitive types lowercase?
      • would be following Java/Rust and a lot of languages
  • follows the good ol' describe

Not liked:

list(int)

Conclusion for this meeting

General preference for the more explicit style Table<...>
(benefit of the "nominal" type for containers that we could hide the implementation details or specialize in the future if we want a columnar table type or different maps instead of record)

Lightning round: $in

  • issue: its non streaming behavior is not quite obvious
  • Jakub: we got pretty used to it
  • Maybe warning/linting if you use it at the first pipeline element of a block/closure 
    ​​​​# this is ok

​​​​def len [] {
​​​​  str length
​​​​}

​​​​# this is not ok? based on performance/streaming properties
​​​​# but more explicit
​​​​def len [] {
​​​​  $in | str length
​​​​}
  • JT: it makes things obvious in some places: 
    ​​if ($in | str length) { ... }
​​if (str length) { ... }
  • Automagical optimization?
    • eliding it in the leading pipeline position internally before evaluating?
    • is it too surprising?
    • JT: let x = $in is the same as let x = ($in)

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