Nushell core team meeting 2023-10-11

Attendees

• Antoine
• Andres
• Darren
• JT
• Michael
• Jakub
• Reilly
• Stefan

Agenda

• nuls as a Rust implementation of the VS code language server components
  • currently still shelling out to the binary
  • When to land in our organization/porting of other editor extensions
  • How to integrate?
    • Separate crate
    • Separate Repo
    • Built into nushell
• 0.86 release on 2023-10-17
  • Things ripe/not ripe?
  • Who takes care of what?
• 1.0 gates, locking down distractions
• Thoughts on $db (darren)
• Is the current meeting time ok? Would 1 hour earlier be better for you?
• Provide feedback on ls command/utility separation changes 10651
• Provide feedback on from csv: streaming 10674
• Value::Stream
• Value/Type::Path #10679

Discussed Topics

nuls - LSP implementation

JT: inside nu have a lsp mode to launch so all editors with LSP support can use it
nuls repo implements the json/rpc side of the LSProtocol

if we move those under nu would save us going through the --ide.. flags

Would add a dependency on the whole tokio/tower stack https://github.com/jokeyrhyme/nuls/blob/main/Cargo.toml

Try to get it in one binary.
Open Q: check the growth in dependencies and binary size -> optimize if necessary

Probably not as a feature flag but keep the burden in check.

VScode extension/neovim would launch nu --lsp ... if available instead of running through nu --ide...

Conclusion: Massive props to @jokeyrhyme, lets try to get it in the mainline nu

Upcoming release

• cp is now uutils and we have cp-old as a backup
  • propably rename the files for discovery
• Improved completions looking good for paths!
  • quoting bug seems to be related to the way we look at the shapes
• no more big outstanding changes that look ready to go in
  Button pushing: JT would be ready

1.0 and what we should reject

JT: our default should be no to new features
Darren: case by case basis
Stefan: look out for the things we would not be able to simply enhance post 1.0

$db proposal

is this a post 1.0 feature
would we want to try it right now

Jakub: would this be a global mutable variable but it is CAP

Landing it so that people depend on it: we would have three datamodel

• the core nu values with all its command
• database with sql and need for some commands
• dataframes with its currently separate commands

Darren's thoughts - We'd ideally hide the sql syntax from users with a group of commands (named store?) that easily access the nudb table, create new tables, create new databases, allow typical CRUD type sql stuff. for more advanced users they have full access to sqlite via queries like $db | query db 'select * from nudb where blah = 1'. The idea is just to make it trivially easy to store and retrieve temporary data in a fast in-memory db.

JT's point about translating records, tables, lists, etc, (does SQLiteDatabase contain those translations today?) is valid but if we use the (unwritten) store commands, they could do that for us.

meeting time conversation

mostly around DST (we schedule based on US DST switch day)

JT and the folks in europe would be ok with an earlier meeting, problematic for WindSoilder

PR proposals to discuss

ls/glob (proposed factor ls into smaller bits.)

Contributor put in some important thought -> we want to encourage that in a productive direction

We are not yet convinced on the impl. How would those composable parts play out.

Good things:

• lazy loading of data in the ls output for performance
• globbing is currently split between nu-glob (fork of o.g. glob crate used in ls) and wax (glob command)
  • full glob syntax has some surprises for folks in desktop environment: foo[1].txt

Darren: No way to turn glob off elegantly, we can't tell a glob from a filename inside a command.

• command flags? e.g. --no-glob
• aNotHer string type e.g. r"raw string literal syntax"

Remember consistency is only a tool for ergonomics

streaming of from csv -> how to stream from/general fallible streaming

General observation we need to delay failing in some streaming situations to the point where we encounter the error to remain fast and streaming.

Streaming as a first class citizen

Not just PipelineData streams that get collected in a lot of places (assigning to a variable, evaluated as an expression)

Ideas around a Value::Stream that behaves like an iterator came up in looking at the effort necessary

would need to be explicit so let x = lsis not surpisingly hard to work with if ls is able to be streamable.
Have an explicit into iter/into lazy or whatever command

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