# Nushell core team meeting 2023-01-11

## Attendees

- Stefan
- Reilly
- Darren
- WindSoilder
- Michael
- Jakub

## Agenda

- Short update how the release was going
- Directory as a module / project structure
- popular request: drop completions files to a directory
- Subexpressions (and other cases) not preserving pipeline metadata
- we need to preserve the metadata when pipeline transforms into a value
- metadata is not used often (only for LS_COLORS and something with html)
- context: https://github.com/nushell/nushell/pull/7689

# Discussed Topics

### Release
nu-release script needed some tweaks due to dependency ordering
Let's try out Jakub's script next time and maybe move it to CI
Smooth sailing with the release notes
Lots of button-pressing
First release ever that JT didn't do.
Surprisingly few complaints about breaking changes!

## PR https://github.com/nushell/nushell/pull/7621

Some escape logic needs to be checked

Failing to parse a record causes failing parse as closure

Possibly related subexpression/parenthesis parsing weirdness

# This is fine
touch a)
let x = (open a))

## Directory as a Module

Currently you need to specify each file you want to import (very much C style)
(even Rust supports some flexibility in the modules?)
Would be great to make the config modular by having just folders for completions/themes etc.

Q: Darren will this bring us closer to requiring/supporting namespaces?
Do we need special namespacing syntax?

Q: WindSoilder Would we have to introduce visibility modifiers? Every file (and its child symbols would be public). (Jakub: could this be addressed by being picky with the directory structure in your project)

viking/
+- spam.nu
+- eggs.nu

# viking/spam.nu
export def foo [] { 'foo' }

# viking/eggs.nu
export def bar [] { 'bar' }

> cd viking
> use spam.nu
> spam foo

> use viking

> viking spam foo
foo

> viking eggs bar
bar

> use viking/*  # with slash
> use viking *  # without slash

> spam foo
foo

> eggs bar
bar

> use viking/spam.nu foo  # with slash
> use viking spam.nu foo  # without slash
> use viking spam foo     # without slash or explicit filename (conflicts with current system)

> foo
foo

# should this even be allowed?
> use viking/* [foo bar]  # with slash
> use viking * [foo bar]  # without slash

> foo
foo

> bar
bar

## `main` in a module

Could we export the core command `main` of a module as a command with the name of the module

use-case `help` command: subcommands
you can not define main command and subcommands in the same module (as modules are structured like subcommands)

# spam.nu

def foo [] { 'foo' }

export def main [] {
    foo
}

> use spam.nu

> spam
foo

> nu spam.nu
foo

### Related: `main.nu`

viking/
+- main.nu

# main.nu

export def main [] { 'foo' }

> use viking

> viking
foo

`main` would be a special name (as it already is)
similar to `__init__.py`/`init.lua`/`index.html`

Would be a good starting point to expand your config from a single module to bigger

Remark Darren: loading order would become relevant (especially for the config)
- Suggestion Jakub: define a order in a static startup script?

## `ENV_CONVERSIONS`

They don't work in the `config.nu` file
They will become active after `config.nu` is sourced
This leads to complexity when you want to work with PATH variables in the config (most likely place to do that!)

Darren: do we want to have a more descriptive structure to the root config files that consists of a file that invokes a bunch of scripts in a particular order (would get rid of the existing split of `env.nu`, `config.nu`)

Ex: `config.nu`

source envvariables.nu
source themes.nu
source completions.nu

Jakub: would this make this readonly?
Would we need to passes to get around the explicit parse/eval split

Concluding remarks from Michael: it would be cool if we could come up with a solution to address the `ENV_CONVERSION` extra complexity

(JT also had some ideas floating around for config separation)

## PR [metadata for ls colors](https://github.com/nushell/nushell/pull/7689)

Dealing with the metadata throughout execution is a larger problem

Currently we have **Pipeline**metadata, this breaks down as soon as we have to convert to a value (e.g. the result of a subexpression or binding to a variable with `let`)

PR suggestion was to introduce a Value variant with the metadata to wrap the inner value

But this would be a dangerous refactor to do as most commands `match`/`if let` on exact type specific `Value::...` variants and the wrapper would go through the fall through
-> consequence/observation: **We should be doing less matching on `Value` in "application/command" code. Instead make the operations dealing with an opaque `Value` through methods/traits**

Also some understandable resistance on our part on introducing another field on `Value` (see the despanning desires)

Discussed alternative to introducing a new variant: using a custom value
- Pro: uses a trait object (already opaque through that)
- Con: still could fail in many `match`es

Discussion touched on trying to solve the span difficulties and duplication as well
Mentioned:
- `Rc<>` the metadata
- Sharing an object on the heap or the nushell stack that carries both span and optional metada. Refer to it either through a pointer or a hand rolled index. (Maybe have the metadata itself living in a hashmap)
- Again first step would be to have less matches we need to refactor on every experiment.