# Nushell core team meeting 2022-12-07

## Attendees

- Andres
- Darren
- Jakub
- JT
- Michael
- Reilly
- Stefan

## Agenda

- Feedback on 0.72
- Hotfix release and plan going forward for the linux binaries
- Mutability - https://github.com/nushell/nushell/issues/7381
- JT XML update
- lets talk about config JT mentioned yesterday
- Next steps to get to 0.80/1.0

# Discussed Topics

## Feedback on 0.72

Mixed reaction to try/catch. Do we support && and || bash-isms?

`&&` would be trivial to translate to `;` at the moment

`||` could be made possible without too much effort

We should deprecate C-style boolean operators to enable that (already PR ready https://github.com/nushell/nushell/pull/7241)

## Binary releases and the need for a hotfix

Caused some headaches with the python virtualenv CI pipeline

-> observation we should still use 20.04 LTS to have a more lenient GLIBC version

Hotfix process still a bit dependent on JT -> Improvement to bus factor

**Action item** release checklist and share keys necessary

## Mutability - https://github.com/nushell/nushell/issues/7381

A little bit weird how mutability works behind cell path indexing

`upsert` and commands are fine

table
order of column or row index shouldn't matter

assigning to `$tab.col` should probably error
while all proper index should work

But cell path updating for deeply nested structures like XML,JSON should work

## XML

**Goal** have a less yucky representation of XML deserialization (quicker access to the inner data would be great)

JT: looking at how XML to JSON converters serialize the attributes and childs ( and bare tags)

still kinda gross until we decide on how it should be represented. Using `#` in special forms might do the trick.

## Config

https://github.com/nushell/nushell/issues/7371

Chat with Yehuda:

pain of upgrading with each version bump (either burn down and rebuild or pray and read the blog)

Could we separate the config into smaller parts
Parts we can update automatically / or the user in a more granular fashion

File split up
- shouldn't overwhelm the users with way to many files
- but maybe have folders for completions, themes where you can just paste new files
- separate user settings from tedious parts most likely contributed from nu repos or the community
- resiliency how do we error or provide defaults

*Also happening:* Record split up by webbedspace and the follow up PRs

Example power user config:
https://github.com/kurokirasama/nushell_scripts/blob/main/nu_config.nu

Michael:
getting the config setup is right is extremely important to have the community on board and make sure we can help people when it get's even more complicated

JT: good starting point would be the completions as they are currently lackluster by default. maybe completions go in a specific directory so we can ship more
Darren: people are requesting to have a discovery on typical unix path `/usr/share/fish/completions` and `~/.config/fish/completions` or whatever

*Action item:* make sure we can import a folder as a module to load the copletions from it
Question about qualified name for files in the directory and how they appear in the module structure/namespace (concatenating all files sounds bug prone)

Would require additional step either as part of the installer or the initial setup (from the data in the binary)

Lookup paths (do we need more?, we may not have permissions to write to locations installers can write to)

Q: how do we update the subfiles?
Suggestion (JT) hash each config file and check if the hash changed compared to the stored values in the binary (include via `build.rs` or something)

**Conclusion** completions as the first starting point for the config modularization

## Next steps for 0.80 and friends

we made a big step by supporting mutation and more imperative constructs

Q: should we make a version jump soon, as we moved big steps
Stefan: Don't feel pressured to do so and we make bigger leaps and smaller steps anyway

What are the things that feel like missing to reach `0.80` mentally
- Better IDE support
- performance edge cases
- redirection
- error handling in a more granular way
- matching (on types)
- rest of the 90% work for the last 10%

## Typechecking and the problem of out of date documentation

Still breaks the doc update script, we should get that fixed ASAP

https://github.com/nushell/nushell/issues/7320

community was not yet eager to pick it up

**Action item** assign range of commands among the core contributors

Warning:
examples are tested for types by Dan's extension to the examples tester
either add additional examples proving that we behave properly with respect to the types or explicitly disable example checking (and be appropriately lenient with `Type::Any`)

## Dataframeectomy post operative care

no shitstorm yet

small number of complaints (on reddit?)

People probably didn't care enough yet as the integration wasn't as seamless as it could be to be intuitive out of the box, so most probably never used it. (and those that use it maybe compile themselves)

-> polish the plugin interface for 1.0 (so it can be versioned and relied upon)
-> 2.0 can bring more tight coupling for more high performance plugins without designing by commitee now (missing killer tool for tigh coupling: wasm, missing stable abi, extism?)

Should we commit to particular `nu-protocol` internals for 1.0
General sense, arriving at the good set of core commands is more relevant to the users.

Ideas around:
- `Value::Table` that would encapsulate the implementation details (row-based, column based for dataframe)
- overlays to enable special commands
- having the core commands exposed to other commands (mini nu virtual machine?)
- would this lend itself towards to doing vtable/enum-dispatch OOP-style overloads of commands or command internal operations