nushell/crates/nu-std
Tim Martin 153b45bc63
Surprising symlink resolution for std path add (#13258)
# Description
The standard library's `path add` function has some surprising side
effects that I attempt to address in this PR:

1. Paths added, if they are symbolic links, should not be resolved to
their targets. Currently, resolution happens.

   Imagine the following:

   ```nu
# Some time earlier, perhaps even not by the user, a symlink is created
   mkdir real-dir
   ln -s real-dir link-dir

   # Then, step to now, with link-dir that we want in our PATHS variable
   use std
   path add link-dir
   ```

In the current implementation of `path add`, it is _not_ `link-dir` that
will be added, as has been stated in the command. It is instead
`real-dir`. This is surprising. Users have the agency to do this
resolution if they wish with `path expand` (sans a `--no-symlink` flag):
for example, `path add (link-dir | path expand)`

In particular, when I was trying to set up
[fnm](https://github.com/Schniz/fnm), a Node.js version manager, I was
bitten by this fact when `fnm` told me that an expected path had not
been added to the PATHS variable. It was looking for the non-resolved
link. The user in [this
comment](https://github.com/Schniz/fnm/issues/463#issuecomment-1710050737)
was likely affected by this too.

Shells, such as nushell, can handle path symlinks just fine. Binary
lookup is unaffected. Let resolution be opt-in.

Lastly, there is some convention already in place for **not** resolving
path symlinks in the [default $env.ENV_CONVERSIONS
table](57452337ff/crates/nu-utils/src/sample_config/default_env.nu (L65)).
   
2. All existing paths in the path variable should be left untouched.
Currently, they are `path expand`-ed (including symbolic link
resolution).

   Path add should mean just that: prepend/append this path.

Instead, it currently means that, _plus mutate all other paths in the
variable_.

Again, users have the agency to do this with something like `$env.PATH =
$env.PATH | split row (char esep) | path expand`.

3. Minorly, I update documentation on running tests in
`crates/nu-std/CONTRIBUTING.md`. The offered command to run the standard
library test suite was no longer functional. Thanks to @weirdan in [this
Discord
conversation](https://discord.com/channels/601130461678272522/614593951969574961/1256029201119576147)
for the context.

# User-Facing Changes

(Written from the perspective of release notes)

- The standard library's `path add` function no longer resolves symlinks
in either the newly added paths, nor the other paths already in the
variable.

# Tests + Formatting

A test for the changes working correctly has been added to
`crates/nu-std/tests/test_std.nu` under the test named
`path_add_expand`.

You can quickly verify this new test and the existing `path add` test
with the following command:

```nu
cargo run -- -c 'use crates/nu-std/testing.nu; NU_LOG_LEVEL=INFO testing run-tests --path crates/nu-std --test path_add'
```

All commands suggested in the issue template have been run and complete
without error.

# After Submitting
I'll add a release note to [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged.
2024-06-28 18:11:48 -05:00
..
src Revert "Remove std::env::set_current_dir() call from EngineState::merge_env()" (#12954) 2024-05-24 11:09:59 -05:00
std Surprising symlink resolution for std path add (#13258) 2024-06-28 18:11:48 -05:00
tests Surprising symlink resolution for std path add (#13258) 2024-06-28 18:11:48 -05:00
Cargo.toml Bumping version to 0.95.1 (#13231) 2024-06-25 18:26:07 -07:00
CONTRIBUTING.md Surprising symlink resolution for std path add (#13258) 2024-06-28 18:11:48 -05:00
LICENSE add LICENSE to nu-std (#8803) 2023-04-07 13:39:21 -07:00
README.md fix nu-std README (#11244) 2023-12-06 16:26:02 +01:00
testing.nu Update PR template (#12838) 2024-05-13 08:45:44 -05:00

Welcome to the standard library of `nushell`!

The standard library is a pure-nushell collection of custom commands which provide interactive utilities and building blocks for users writing casual scripts or complex applications.

To see what's here:

> use std
> scope commands | select name usage | where name =~ "std "
#┬───────────name────────────┬──────────────────────usage──────────────────────
0│std assert                 │Universal assert command
1│std assert equal           │Assert $left == $right
2│std assert error           │Assert that executing the code generates an error
3│std assert greater         │Assert $left > $right
4│std assert greater or equal│Assert $left >= $right
             ...                                     ...
─┴───────────────────────────┴─────────────────────────────────────────────────

🧰 Using the standard library in the REPL or in scripts

All commands in the standard library must be "imported" into the running environment (the interactive read-execute-print-loop (REPL) or a .nu script) using the use command.

You can choose to import the whole module, but then must refer to individual commands with a std prefix, e.g:

use std

std log debug "Running now"
std assert (1 == 2)

Or you can enumerate the specific commands you want to import and invoke them without the std prefix.

use std ["log debug" assert]

log debug "Running again"
assert (2 == 1)

This is probably the form of import you'll want to add to your env.nu for interactive use.

✏️ contribute to the standard library

You're invited to contribute to the standard library! See CONTRIBUTING.md for details