really love the idea of being able to change config settings so easily.

I like the idea but I don't like special-casing $env. I think we could allow = to upsert instead of update for all variables. And/or implement the |= operator proposed by JT: $env |= upsert PYTHON_IO_ENCODING utf8. Anyway, this feels like a language design question that should be discussed more carefully.

But $env is kinda special, no? As noted somewhere, the environment is largely an OS concept rather than something nushell. Or at the least it has special platform-specific considerations. Which is not to say it $env should work differently, just that working differently may be justified.

From the language point of view $env is just a variable, a record, like $nu, for example. We could treat it as if it was defined with mut env = ... instead of let env = ... which I'm totally fine with but this PR also suggests a specific language extension that applies only to $env. Special cases increase mental overhead when learning the language and also add extra maintenance effort. Sometimes, there is a good reason to introduce a special case, but in this case I believe we don't need one.

I like the idea but I don't like special-casing $env. I think we could allow = to upsert instead of update for all variables. And/or implement the |= operator proposed by JT: $env |= upsert PYTHON_IO_ENCODING utf8. Anyway, this feels like a language design question that should be discussed more carefully.

Are you saying this part ?

@webbedspace We discussed this a bit and it seems like we could support adding new record fields with =. So, you should be able to do mut rec = { a: 10 }; $rec.b = 20. If you could change this PR to allow that for all variables without special-casing $env, we could merge it.

Also, it would need tests.

@webbedspace We discussed this a bit and it seems like we could support adding new record fields with =. So, you should be able to do mut rec = { a: 10 }; $rec.b = 20. If you could change this PR to allow that for all variables without special-casing $env, we could merge it.

Also, it would need tests.

OK, I've now done all that. Note that I had to do a number of non-trivial tweaks in order to make mutable lists like mut a = {a:[0]}; $a.a.1 = 1 work correctly.

I'm not sure how others will feel about these changes but I'm loving playing in this PR. I love how it makes changing things so easy. The only thing that took me by surprise was the ability to mutate the next indexed element. Example:

> mut a = [0 1 2]
> # Test to see if $a.3 exists
> $a.3
Error: nu::shell::access_beyond_end (link)

  × Row number too large (max: 2).
   ╭─[entry #2:1:1]
 1 │ $a.3
   ·    ┬
   ·    ╰── index too large (max: 2)
   ╰────

> # Append by indexing into a non-existent next index
> $a.3 = 3
> $a
╭───┬───╮
│ 0 │ 0 │
│ 1 │ 1 │
│ 2 │ 2 │
│ 3 │ 3 │
╰───┴───╯

> # Test if you can skip an index
> $a.5 = 5
Error: nu::shell::access_beyond_end (link)

  × Inserted at wrong row number (should be 4).
   ╭─[entry #43:1:1]
 1 │ $a.5 = 5
   ·    ┬
   ·    ╰── can't insert at index (the next available index is 4)
   ╰────

I mean, I could live with this and I think it's kind of cool, but it took me by surprise.

That's what I had to do to take the concept of "mutating via insert", which already exists for records, and "make it make sense" for lists. In Javascript, of course, you can just do a = [0]; a[1000] = 1 and it "works", but the gap creates 998 "holes" (similar to Nushell table holes), and since those don't exist for Nushell lists (and Rust vecs) I had to add that restriction and error message.

EDIT: Forgot to mention, this is also how upsert currently works: try [0] | upsert 1 'foo'

OK, looks good, let's try it. Thanks!