# Nushell core team meeting 2024-01-03
## Attendees
- Ian
- Jakub
- Stefan

## Agenda

- [x] case-insensitive env vars on Windows
- [#11268](https://github.com/nushell/nushell/pull/11268): Path vs PATH
- [#11432](https://github.com/nushell/nushell/pull/11432): all env vars
- [x] `--` in signatures ([#11435](https://github.com/nushell/nushell/pull/11435))
- [x] add support for repeated flags in signatures, e.g., `...--flag: int` ([#11431](https://github.com/nushell/nushell/pull/11431))
- [x] Nupm: avoid `use ../../foo/bar.nu`
- Something analogous to Rust's `crate`?
- [x] Nushell-backed repository to host important integrations (community-contributed, like nu_scripts), such as:
- [ ] packaging, e.g., nix flakes [#8155](https://github.com/nushell/nushell/pull/8155), [#10945](https://github.com/nushell/nushell/pull/10945)
- [ ] editors, e.g., tree sitter neovim integration [tree-sitter-nu:#57](https://github.com/nushell/tree-sitter-nu/pull/57)
- or is [awesome-nu](https://github.com/nushell/awesome-nu) and [showcase](https://github.com/nushell/showcase) enough?

## Discussed Topics

### case-insensitve env vars on Windows

No objections about having case-insensitive env vars matching on Windows. We'd rather have a general solution working for all env vars instead of just Path/PATH

### `--`

def --wrapped `cargo run` [--flag, ...rest] { ... }
cargo run --flag -- --flag  # throws an error
cargo run --flag '--flag'

Needs to be squared with spread operator

cargo run --flag 'abc' ...[a b c] -- --flag  # rest collects to ['abc' a b c --flag] ?
cargo run --flag 'a' ...[b c]                # rest collects to [a b c]
cargo run --flag ...[--flag]                 # workaround instead of --
cargo run --flag ...[a b c]                  # or only this allowed?

`--` is quite common, many people expect it to work, we can try it.

### `...--flag`

For internals you should already be able to use lists.
For externals/wrapping:
Can be worked around with `--`. This gives `--` a + point.

### General observation

Different level of flag/argument syntax for internal/external commands

We internally have more explicit ways to express passing lists or records.

External commands have developed more wild-west of parsing syntax.
- repeated flags
- relevant https://github.com/nushell/nushell/pull/11431
- `-vv` repeat as increased strength
- different value separation logic
- spaced/directly after shortflag/with `=`
- shortflag chain/longflag with single `-`
- `--` as a separator

we have to be judicious what we include for our argument parsing

### Paths in imports

(Discuss the existing problem with `nupm` with amtoine, when he is around)

We shouldn't allow absolute paths imports (`use /usr/bin/foo.nu`).

### Curating "official" nushell, scripts integrations

- nix flake(s)
- someone moved something to their own repo (apparently doesn't need to be in the main repo, we previously rejected several PRs)
- plugins and integrations on `awesome-nu`
- packaging maintainers outside nushell org
- when is it helpful to take over the responsibility
- testing/active support as an inclusion criterion?
- (tier support)

What should go here, to nu_scripts, to awesome-nu, etc.? We should make it clearer what goes there, maybe make a list of candidates.

One criterion could be that each integration would have some tests running in the CI that would need to keep green.

## Issues
> :bulb: the issues which [needs-core-team-attention](https://github.com/nushell/nushell/labels/needs-core-team-attention)

> :bulb: **Note**
> to list all the PRs currently [opened in `nushell/nushell`](https://github.com/nushell/nushell/pulls):
> ```nu
> gh pr list --json url,number,author,title
> | from json
> | each {|i|
> $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
> }
> | reverse
> | to text
> ```