owned this note   changed 2 years ago  
Published Linked with GitHub

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

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

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

Dealing with the metadata throughout execution is a larger problem

Currently we have Pipelinemetadata, 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 matches

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.
Select a repo