# Nushell core team meeting 2024-12-04
## Attendees
- Ian
- Piepmatz
- Stefan
- Michael
- Douglas
- Jack
- Rose
- Andy
- Devyn
- Maxim
- Wind

## Agenda

### Remaining items from last weeks meeting:

- [x] Moving HTTP commands to a plugin ([#14432](https://github.com/nushell/nushell/pull/14432))
- Stefan comment pre-meeting: given the valid concerns about security and quality of our curl-we-have-at-home, has our stance here impact on enhancement PRs to the `http` family e.g. [#14340 websockets/streaming](https://github.com/nushell/nushell/pull/14340) or the already merged [multipart forms that caused semver breakage due to upstream changes](https://github.com/nushell/nushell/pull/13532#issuecomment-2489317361), I am pro minimal `http` as part of the default to bootstrap a `nupm` or further plugins from the single installed binary/package.

### New Items

- [x] Deprecating `$env.NU_XXX_DIRS` and `env.nu` (see notes below)
- [ ] per Windows drive Working directory - What is compatibility what is familiarity
- [x] Status of std-rfc?

## Discussed Topics

**Deprecating `$env.NU_XXX_DIRS` and `env.nu` (see notes below)**

Proposed steps. Release one:
1. Print a deprecation warning if the user sets any value to `$env.NU_XXX_DIRS` (but keep it working)
2. Change default config etc. to use the const version and do not generate `env.nu` automatically anymore.
3. Print a deprecation warning if the user has `env.nu` (but still read it)

Then, next release:
1. Remove `$env.NU_XXX_DIRS` functionality, but still print a warning if the user sets a value to it
2. Do not read `env.nu` anymore, but still print a warning if it exists

Then, next release:
1. Remove deprecation warnings

Alternatively, keep as escape-hatch:
1. Rename env.nu to preconfig.nu
2. Don't automatically generate preconfig.nu for new users
Need ENV_CONVERSIONS to update state immediately or change to const

### `http` should it be a plugin?
- http:
- security concern, having the process launching bits with the web interacting part. (counter: every process could exec/fork, PS does it as well)
- general security concerns regarding our implementation (is it our when we pull in dependencies, trust, quality of dependency)
- scope creep, can't rollback/version behavior in Nushell main as easily as with a plugin
- basic `http get` is a killer feature with wow factor of Nushell
- plugin side
- under developed for the default distribution of plugins
- currently some packages ship plugins some not (e.g. winget has *some*)
- General vibe:
- we for now want the `http get`
- watch out for scope creep in main impl -> develop a plugin for new stuff first
- Suggestion to Ian to use his PR as a basis for an http plugin that can be further developed over time along with yet another awesome example of how to write a more "sophisticated" type of plugin.
- can also be used for future development of features we want in http that would not be part of the core http command set

### std rfc folder -> staging round for `std`
- in nu_scripts std-lib-candidates
- now