`basher install package@ref` fails binary linking during installation

[joseph-galindo]

Hello. I am thinking of prepping a PR to fix this issue in my free time, but I wanted to at least file the bug+workaround first. Just in case anyone else is running into the same thing.

This is a bug I noticed with basher installations of 16bf157 . Basically, the gist is like this.

Repro steps

Suppose you have a basher package and want to install it by a specific git ref. We will use https://github.com/UrbanCompass/hnvm for this example.

The bug repro from scratch, on a clean system, would look something like this:

# Set up basher from scratch on a clean system
$ git clone --depth=1 https://github.com/basherpm/basher.git ~/.basher
$ cd ~/.basher
$ git checkout 16bf157c8570f24f86e8b4a11d1f5205e840fd96
$ cd ~
$ export PATH="$HOME/.basher/bin:$PATH"
$ eval "$(basher init - bash)"

# basher should now be available to use on PATH, so use it to install a package@ref
$ basher install UrbanCompass/hnvm@v0.15.10
Cloning into '/Users/joseph.galindo/.basher/cellar/packages/UrbanCompass/hnvm'...
remote: Enumerating objects: 41, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 41 (delta 7), reused 20 (delta 1), pack-reused 0 (from 0)
Receiving objects: 100% (41/41), 94.75 KiB | 9.47 MiB/s, done.
Resolving deltas: 100% (7/7), done.
Note: switching to 'f8b3dbdfbf315ccff37782cc88f6eecf9b0b7186'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

find: /Users/joseph.galindo/.basher/cellar/packages/UrbanCompass/hnvm@v0.15.10: No such file or directory

Basher will still list this package as installed through basher list:

# list installs
$ basher list
UrbanCompass/hnvm

# list where this package was installed on disk
$ basher package-path UrbanCompass/hnvm
/Users/joseph.galindo/.basher/cellar/packages/UrbanCompass/hnvm

But, the installation did not technically finish fully. This can be problematic, especially in cases like this package, where the UrbanCompass/hnvm package lists other DEPS (following deps docs) that need to be installed after this point.

Bug Explanation

They key part of the bug is this:

find: /Users/joseph.galindo/.basher/cellar/packages/UrbanCompass/hnvm@v0.15.10: No such file or directory

The best I can tell, it is related to how binary linking happens during install, specifically here:

basher/libexec/basher-_link-bins

Line 18 in 16bf157

bins=($(find "$BASHER_PACKAGES_PATH/$package" -maxdepth 1 -mindepth 1 -perm -u+x -type f -or -type l))

Basher will pull down the git contents of the installed package, and place them at ~/.basher/cellar/packages/UrbanCompass/hnvm.

However, when the link-bins step happens, it is instead looking for those files at ~/.basher/cellar/packages/UrbanCompass/hnvm@v0.15.10. There will be no files there, so the find call errors out, which ends the installation process prematurely.

At a high level, it seems like the value of $package is being used for both the target being installed, and where that target will be placed on disk. But these two aren't always the same, at least for installing by package@ref.

Bug Workaround

To work around this bug, I found that the simplest way is to provide the folder arg. Like so:

# install by ref, and provide the folder arg
$ basher install UrbanCompass/hnvm@v0.15.10 UrbanCompass/hnvm
Cloning into '/Users/joseph.galindo/.basher/cellar/packages/UrbanCompass/hnvm'...
remote: Enumerating objects: 41, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 41 (delta 7), reused 20 (delta 1), pack-reused 0 (from 0)
Receiving objects: 100% (41/41), 94.75 KiB | 7.90 MiB/s, done.
Resolving deltas: 100% (7/7), done.
Note: switching to 'f8b3dbdfbf315ccff37782cc88f6eecf9b0b7186'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

Cloning into '/Users/joseph.galindo/.basher/cellar/packages/stedolan/jq'...
remote: Enumerating objects: 446, done.
remote: Counting objects: 100% (446/446), done.
remote: Compressing objects: 100% (385/385), done.
remote: Total 446 (delta 26), reused 338 (delta 20), pack-reused 0 (from 0)
Receiving objects: 100% (446/446), 1.26 MiB | 14.66 MiB/s, done.
Resolving deltas: 100% (26/26), done.
Submodule 'vendor/oniguruma' (https://github.com/kkos/oniguruma.git) registered for path 'vendor/oniguruma'
Cloning into '/Users/joseph.galindo/.basher/cellar/packages/stedolan/jq/vendor/oniguruma'...
remote: Enumerating objects: 15039, done.        
remote: Counting objects: 100% (4872/4872), done.        
remote: Compressing objects: 100% (260/260), done.        
remote: Total 15039 (delta 4717), reused 4614 (delta 4612), pack-reused 10167 (from 3)        
Receiving objects: 100% (15039/15039), 6.37 MiB | 16.73 MiB/s, done.
Resolving deltas: 100% (11357/11357), done.
Submodule path 'vendor/oniguruma': checked out '4ef89209a239c1aea328cf13c05a2807e5c146d1'

Note that in this case, there is no more find error thrown, and the listed DEPS (jq) fully installs this time. The whole package installation finishes successfully, and can be treated as safe to use going forward.

Bug Fix

I need to investigate this more. I noticed that this bug with basher install package@ref doesn't happen on really old versions of basher, like d53eb7b . So a git bisect will probably help me track down exactly when this bug was introduced.

[ChadThackray]

Thank you for the really detailed bug report! It looks like I introduced this in e4fea83. I've submitted a PR to fix should get merged soon