# Nushell core team meeting 2022-09-07

## Attendees

- Stefan
- JT
- Jakub
- Darren
- Reilly
- Storm
- Andres

## Agenda

- [Pillars of Nushell](https://hackmd.io/HOYbgsN9QmiOkIK9WY_6uQ): Common themes
- Syntax changes:
- brackets vs parens in defs
- Afterthoughts: dollarless variables
- Proposed: space vs dot for subcommands
- Contributor sustainability
- Team documentation
- Roles for our club members
- Dev docs
- Issue triage
- `source-env` failure [#6513](https://github.com/nushell/nushell/discussions/6513) and [#6510](https://github.com/nushell/nushell/issues/6510)
- being a shell - discussion of `source` in general
- JT's cursed syntax idea

# Discussed Topics

## Pillars of nushell

We have a collection on [Pillars of Nushell](https://hackmd.io/HOYbgsN9QmiOkIK9WY_6uQ)

Wait for everyone to have

## Syntax changes

Strong engagement on the polls (> 60 respondents)

- removing the `$` on the variable (pulled for now)
- No reactions on revert of `$` yet with the release
- (62% percent for dedollarfication in the polls) but we weren't yet technically convinced
- `[]` vs `()` for `def`s
- Space vs dot for subcommands
- dot has IDE advantages
- see comments by JT in the last section (potentially new unifying semantics)

## Involving the community better

We should keep up on issue triage and PR review

-> try to give our club PR review and issue triage rights (check Github options)

## How can we reduce the problem "People don't understand nushell properly"

1. People using nushell
2. People contributing to nushell
- Not fully aware of general structure
- Parsetime philosophy

Maybe: A blogpost about the parse and eval time to point to (on top of "thinking in nushell")

## Contributor book

Desired:
- How to write a command + rough guidelines
- Where to place your tests
- Examples
- different integration tests
- How the parser etc. are structured

READMEs in the main repo have advantages in keeping it in sync (every developer would have it on their disk already)

## Testing

We don't get all the benefits from automated testing at the moment.

**Problem:** Running the test suite with dataframes is slow

99% solution: not always recommend running `cargo test --all --features=extra`

Maybe a nushell helper script for the developers to trigger the right things locally

Idea: nushell assertion commands to better write better nu tests

Most people won't learn nushell internals. However, a good way to ensure that the nushell model is followed is to add tests for 100% coverage of our codebase. This way, if rules are broken, tests will catch them.

## `source-env` failure

We want to be able to hand a path to `source-env`
Problem: We allow blocks in the env
Currently we don't absorb the new blocks (not allowed at eval time by current design)

Currently works for data only
Blocks and defs break

*Problematic usecase right now:* prompts (They use a block and should be sourceable)

Hotfix (not so nice): rip `source-env`
OR require static path (defeats the purpose of source work)

Hotfix: error on block import properly

Initially intended to go alongside with modules (they now have a `export-env` block to aggregate the data segment)

Metaquestion: How much do we embrace the shellness (leading to allowing `eval` or `source`)

> Andres from early nushell development: Can we keep the parser agnostic from shell things? (concern at the time IDE parsing/primary parsing)

Can we have valid different flavors of the parser (shell flavor, static language flavor)?

-> problem of consistency, hard to follow for the users if stuff only works conditionally.

Eval exists in other scripting languages (Dave?: on eval also description of side effects in the form of new prototypes)

**Fix now:** properly error out on blocks now, decide on the further direction later. Also address the block post. (pointer in the error message)

## Philosophical discussion in the direction: Pillars of nushell

> JT: If we want to reach a large userbase we can not just be a GUCCI shell

Areas: shell, devops, dataframes, DSL (value add by adding a shell scripting like tool for an existing ecosystem), + crazy things

**Open Q:** How can we crack the new area and attract many new users and contributors

Historical example: Ruby only made inroads around the world with Ruby on Rails. Python got its killer application with the numpy/scipy ecosystem (and some webstuff...)

> We need stakeholders that feel empowered to add commands or push nu(shell) in nu directions

e.g. Andres' data project -> data commands
Idea floating around to pick up: test runner -> devops concerns could be addressable by nu

### Gists of comments (please expand or correct if I misrepresent you)

- Stefan: there are areas that make it feel hard to program more complex things. personally miss first-class functions and user defined types allowing function dispatch or typecheck. would love to escalate from a oneliner
- Jakub: maybe work around the shell like syntax but favor static/structured semantics for scripts and allow going beyond scripts into large applications
- Reilly: writing scripts feels harder than necessary now, maybe have 2-flavors to feel more "C-style syntax" like in larger scripts compared to the shell experience
- JT: with jakt NES emulator project, could a NuES be written? Ambitious project that is passion driven.

## Syntax and typesystem idea from JT

Let's embrace the overloading based on types -> subcommands can be simplified and made consistent

# Current
"hello world" | str split " "

# Future
"hello world" | str.split " "

# str is a module
# modules can say they extend a certain type
# `str` extends/enhances `string`

# Also allow
"hello world".split " "

Q: how to constrain a string to be a path

We like the idea