# 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.