Nushell core team meeting 2023-02-15

Attendees

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

Agenda

• Bust up nu-command into 3 crates with the following crate names:

  • nu-cmd-lang
  • nu-cmd-shell
  • nu-cmd-extra

  Here is what I have so far in nu-cmd-lang.

  • core
  • env
  • system
  • shells
  • viewers

  This comes out to be around 257 crate dependencies.

  Here is the logic of why these categories / directories have to be there.

  There are some issues which I need to work out including…

  • it appears that all of the tests are passing except for the plugin tests.

• Some PRs that probably need some decisions to either close or move ahead.

  • https://github.com/nushell/nushell/pull/7829
    • Solution seems like an inappropriate hack.
    • snatch a test, try to tackle the underlying problem.
  • https://github.com/nushell/nushell/pull/7925
    • Show empty records/lists
  • https://github.com/nushell/nushell/pull/8012
    • Progress bar
    • roll your own coreutils
      • Same can be said for fs_extra
  • just for the record
    • https://github.com/nushell/nushell/pull/7641
      • small, just redo it.

• With #clubhouse gone from discord, we should probably go back to core-team members being part of core-team on discord instead of members of particular PR clubs. Thought?

• amtoine's push for the stdlib in nu

  • Reilly: "stdlib" is a potentially confusing name. Implies that the commands written in Rust are not part of the standard library

• Stefan: again to consider 4 week release cycle.

  • the small stuff adds up
  • Being a maintainer feels like walking around the ship of Theseus with a grease gun

Discussed Topics

nu-command cratification

Michael has broken up nu-command into three crates

Two versions to try:
1.) just core (nu-lang effectively ~70 commands)
- version
- help
2.) 4 categories (~257 deps)
- env
- system
- shells
- viewers

How does this interact with the configuration
(Important remark Darren: currently driven by environment system in a part)

State

Tests seem to work
Plugin tests need some work

Qs

Were to place the filesystem commands

How can we provide a menu a la carte
e.g. dataprocessing without the intrusive shell aspects

$env is currently special sauce in the parser (might be more than nu-lang)

implementation details

crates have their own create_default_context
pulling all of them in by merging into the engine state on setup

Nana - a new hope

We can now pick and choose what we ship with nana

as its just an engine state merge it is hot-pluggable

Dataframe

good news in the ecosystem: arrow and arrow2 seem to start to get along (goal one crate)
When is the honeymoon over?
can we build something with it?

What will be our datamodel for dataframy stuff is still open and depends on the ecosystem (let's piggyback on giants for the performance stuff.)

Should be easy to cratify

PR's