Default install directory for 'deno install'

[nayeemrmn]

deno install -h:

...
OPTIONS:
    ...
    -d, --dir <dir>                Installation directory (defaults to $HOME/.deno/bin)
...

Wouldn't it be more intuitive for it to default to $DENO_DIR/bin if it exists?

If someone leaves everything to its default, the installation directory of deno and the installation directory of executables created with deno install will coincide at $HOME/.deno/bin.

In my case, however, I installed deno to /opt/deno and DENO_DIR is set there. Now if I deno install something without -d, it will still be put into $HOME/.deno. It is obviously confusing for this location to exist in my situation. It would be more consistent with the default-only case if the installation directory for deno install defaulted to $DENO_DIR/bin, since DENO_DIR should be known at this time.

[nayeemrmn]

On a related note, deno_install/install.sh says after installation:

Manually add the directory to your $HOME/.bash_profile (or similar)
  export PATH="$bin_dir:$PATH"
Run ' --help' to get started

It should also suggest adding export DENO_DIR="$deno_dir".

[bartlomieju]

Wouldn't it be more intuitive for it to default to $DENO_DIR/bin if it exists?

If someone leaves everything to its default, the installation directory of deno and the installation directory of executables created with deno install will coincide at $HOME/.deno/bin.

Yep, I believe I was supposed to add that but it slipped away somehow. I'll get back with a PR

[bartlomieju]

After some thought I believe that using DENO_DIR as binary installation directory is not the right place.

Using deno_install default installation directory is $HOME/.deno/bin, but $DENO_DIR's location is specific for platform (eg. on Linux it's $HOME/.cache, on Mac it's $HOME/Library/Caches/deno). So it really makes no sense to add additional directory bin to $DENO_DIR just for installing executables, or does it?

Calling for opinions - CC @ry

[nayeemrmn]

Something seems strange here. Let's put aside the behaviour of deno install.

According to deno_install/install.sh, $DENO_DIR is supposed to point where deno (as in the deno executable itself) is installed ($HOME/.deno by default or /opt/deno in my case). This is conventional and intuitive given its name. Setting it prior to installation allows you to specify a custom installation directory. I installed deno system-wide like this:
curl -fsSL https://deno.land/x/install/install.sh | sudo DENO_DIR=/opt/deno sh
I now realise that this was a very recent change, #69.

But $DENO_DIR is also used to store the cache, which explains the locations you're saying it should be set to. I always thought it was strange that the cache was being put into the installation location of deno itself.

Maybe the cache location should use a different environment variable, $DENO_CACHE_DIR? If I'm misunderstanding something, please clarify what $DENO_DIR should be used for and why it is used the way it is in deno_install/install.sh.

[ry]

1. @Nayeem-Rahman - good catch - we're overloading the $DENO_DIR naming. The cache directory and the bin directory for the executable were the same in the past.... I'm still not entirely convinced that it's useful to have the cache in a different platform dependent location.

2. @bartlomieju My only concern is that we don't ask the users to add two directories to their $PATH. One at most. What if we get rid of this useless platform-specific cache directories and just put everything into $HOME/.deno ?

3. It's confusing that the name of the shell script installer repo is "deno_install", but we also have this very different "deno install" (which is in the deno_std/installer directory). We need to rename one of them.

[nayeemrmn]

I guess having everything in the same directory is fine, but

2. ...put everything into $HOME/.deno ?

By $HOME/.deno do you mean $DENO_DIR which defaults to $HOME/.deno? This brings me back to my original point. I think every reference to $HOME/.deno should be replaced by $DENO_DIR except as a default/fallback for when $DENO_DIR isn't set. The deno install subcommand currently disobeys this which leads to a discrepancy when I have $DENO_DIR set to a custom location, as I described up top. Changing this at least wouldn't conflict with any of the goals you mentioned.

[ry]

By $HOME/.deno do you mean $DENO_DIR which defaults to $HOME/.deno?

Yes, that's what I meant.

I think every reference to $HOME/.deno should be replaced by $DENO_DIR except as a default/fallback for when $DENO_DIR isn't set.

Agree.

[nayeemrmn]

Although there is one glaring issue with re-purposing the deno installation directory for the cache. Deno would need root access to write to the cache when, like me, you've installed it to system-wide location like /usr/local or /opt. I don't think this is too much of an edge case but either way it definitely highlights a bad practice. Maybe that needs its own issue.

[ry]

For reference here is where the cache dir is defined:

deno/cli/deno_dir.rs

Lines 102 to 107 in 1fde15c

	// We use the OS cache dir because all files deno writes are cache files
	// Once that changes we need to start using different roots if DENO_DIR
	// is not set, and keep a single one if it is.
	let default = dirs::cache_dir()
	.map(|d| d.join("deno"))
	.unwrap_or(fallback);

[nayeemrmn]

The original proposal doesn't make sense anymore. The closest thing would be $DENO_INSTALL/bin but that variable shouldn't be acknowledged here. $HOME/.deno will work in most cases and doesn't seem that bad to me anymore. Closing.

For anyone interested, the problem persists that the default install directory isn't one that is definitely in the PATH.

I think this kind of thing is exactly what $XDG_BIN_HOME is for, given by dirs::executable_dir():
https://github.com/denoland/deno_third_party/blob/ddb37d7734154c3c07e7c14deaf6523a635e52d8/rust_crates/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.2/src/lib.rs#L116-L127
but as you can see there are no equivalents for macOS and Windows :(. Oh well.

@bartlomieju Perhaps dirs::executable_dir() should be in the fallback chain anyway.