Add dir output when using --download and directory exists

[elibarzilay]

This is the tiny change that I talked about in #831. The actual change is both the extra line, plus a vague highlevel decision to keep this output intact in face of future change.

Looks like a very small change (which I promised :) and also likely to be accepted since it's a harmless one line of output --- BUT --- with this, I can use n to manage the downloading + caching of various versions, but use my own system for actually "activating" it.

In my use case, I'd write a small script that uses n <ver> --quiet --download to just have some version available. With this PR in place, I can parse the output and look for ^ *(mk)?dir : . That gives me the directory which I will then use as a /usr/local/node symlink (with /usr/local/bin/* symlinks into that main node symlink).

AAt a higher level, this makes it possible to use the download-and-cache functionality of n with any way of using the results. This could open up more uses in the future to have more alternative activations.

I specifically think now that some disconnected n link <ver> would be an awkward addition, since it would look like a side-think that is bolted on, since it would be disconnected from the main way of activating a version. That's why I originally thought about something along the lines of adding a "mode" thing, but as I said in that thread, that would be a major change. Especially with things like --cleanup that won't fit with it.

At a minimum, it would make it easy to play with alterrnative activations before adding it to the main code.

[shadowspawn]

I think the information you want may already be available by a different route. There is a supported way to do a lookup to resolve a version:

$ N_MAX_REMOTE_MATCHES=1 n lsr 10               
10.24.1

And an internal behaviour is that full numeric versions do not trigger a lookup to resolve them, so low overhead to use them with further commands. As supporting evidence:

$ time n which 10.24.1
/usr/local/n/versions/node/10.24.1/bin/node
n which 10.24.1  0.02s user 0.02s system 80% cpu 0.044 total
$ time n which 10.24.999

  Error: '10.24.99' (10.24.99) not in downloads cache

n which 10.24.99  0.02s user 0.02s system 79% cpu 0.045 total
$ time n which 10  
/usr/local/n/versions/node/10.24.1/bin/node
n which 10  0.06s user 0.04s system 46% cpu 0.223 total

[elibarzilay]

What I'm talking about is the output of n download, which would also do the download. I don't know how lsr is related here.

Here's a tiny script that uses the extra output line:

#!/usr/bin/env bash

set -eu

die() { printf "%s\n" "$@" 1>&2; exit 1; }
if [[ -z "$1" ]]; then die "missing version arg"; fi
o="$(n download --quiet "$1")"
if [[ -z "$o" ]]; then die "n errored"; fi
rx=$'(\n|^) *(mk)?dir : (/.+)'
if [[ ! "$o" =~ $rx ]]; then die "unexpected output from n:" "$o"; fi
ndir="${BASH_REMATCH[3]}"
if [[ ! -d "$ndir" ]]; then die "n didn't create directory: $ndir"; fi

rm -f /usr/local/node
ln -sv "$ndir" /usr/local/node

As I said, I could use "$(n which "$1")", but why not make that information available from the download since it's already there only inconsistently so (when it generates the directory)?

[shadowspawn]

As I said, I could use "$(n which "$1")", but why not make that information available from the download since it's already there only inconsistently so (when it generates the directory)?

In short, the progress showed by download is to inform a person, not for a script parsing the progress. The which command shows the node location with the expectation that it may be used by scripting.

[shadowspawn]

(n lsr might not be relevant. I thought one of the challenges was "resolving" a version label into a fully qualified version number.)

[shadowspawn]

Using which seems appropriate, say

ndir="$(n which "$1" 2> /dev/null || true)"
if [[ -z "$ndir" ]]; then
    n download "$1"
    ndir="$(n which "$1")"
fi

[shadowspawn]

At a minimum, it would make it easy to play with alterrnative activations before adding it to the main code.

That seems possible with the current code, and in a more robust way than parsing the download progress.