stew search lazydocker does not return lazydocker-high-contrast, which is a fork of lazydocker, for instance. An option to search through forks would be nice.

Currently stew stores all binaries and data in a $HOME/.stew directory but I would like to support the XDG Base Directory Specification instead.

This would mean moving ~/.stew to $XDG_DATA_HOME/stew (or $HOME/.local/share/stew if $XDG_DATA_HOME is not set).

Hey again! opening another issue to keep things tidy.

A really nice addition would be the ability to store binaries under a different name, i.e. renaming a binary foobar to kubectl-foobar.

Hey there,

really like the project! (I actually had an old abandoned python project doing pretty much the same: https://github.com/AFriemann/ghbin)

one thing I noticed while testing is that I can't easily use it for projects that come with multiple binaries like for example ksniff: https://github.com/eldadru/ksniff

I had to manually remove the zip and re-install it. A multi select in the initial installation would be an awesome addition!

Hi, thanks for stew, its been really useful.

I sync my Stewfile between workstations: when I install or update a binary on one PC, I manually regenerate a new Stewfile to propagate the changes to the other.

Could we set a Stewfile to be updated automatically after every operation? Something like stew file ~/dotfiles/Stewfile. I could contribute a PR for this.

Closes #14. This PR adds the ability to install from a given Stewfile.lock.json.

Its worth mentioning that the given lock file is assumed to be different from the local Stewfile.lock.json that exists in the stewPath. If necessary, I can include a check to ensure the local $stewPath/Stewfile.lock.json cannot be used.

This PR introduces the ability for users to configure the stewPath (which is where stew data is stored - originally hardcoded as ~/.stew) and the stewBinPath (which is where binaries are actually installed - originally harcoded as ~/.stew/bin). There are 3 ways to configure these:

1. Upon initial installation with the install.sh script, it will prompt you to configure these.
2. If you install the stew binary without the install.sh script or later realize you want to change them, you can use the new stew config subcommand.
3. You can manually edit the stew config file ($XDG_CONFIG_HOME/config.json or ~/.config/stew/config.json on Linux/macOS and ~/AppData/Local/stew/Config/config.json on Windows)

Additionally, the new default locations for stewPath and stewBinPath follow the XDG spec:

| | Linux/macOS | Windows | | ------------ | ------------ | ---------- | | stewPath | $XDG_DATA_HOME/stew or ~/.local/share/stew | ~/AppData/Local/stew | | stewBinPath | $XDG_DATA_HOME/stew/bin or ~/.local/share/stew/bin | ~/AppData/Local/stew/bin |

This PR adds a rename subcommand to allow users to rename binaries. This is preferred over using an alias in your .zshrc or .bashrc because renaming a binary with rename will update the Stewfile.lock.json as well as the binary name itself. This means that commands like stew uninstall <renamedBinary> and stew upgrade <renamedBinary> will work, which is not true if you use an alias.

Users will also automatically be prompted to rename a binary if:

1. The asset itself is the binary. Often these have names like binary-v0.0.1-darwin-arm64, which is not the name that people want to type into the command line.
2. If the binary is not automatically detected inside an archived asset (which can happen if 0 or >1 executable files are found in an archive). After selecting the binary, they will be prompted to rename it.

Finally, this PR switch out any usage of the path library in favor of the filepath library which uses / or \ in an operating-system compatible way. path only uses /.

Stabilized configuration updates.

• Changed config.json -> stew.config.json
• Changed default stewBinPath to ~/.local/bin
• Warn user if stewBinPath not in PATH
• Prompt user to set up config values if stew.config.json not found
• Update curl install script accordingly

Added brew tap as an installation option.

Update docs.

It is common when, at release, a binary is packed with man file and some others into an archive. Like zoxide, btop and many others. It will be awesome if stew will be able to unpack such archives and allow choosing a binary to install.

When we run stew search, it could be beneficial to have an ability to press, for example, Ctrl-o to jump to repo's page for more details. What do you think?

stew upgrade --all command throwing error, if there is no update found. including this command in topgrade (r-darwish/topgrade) also throwing error status.

Great tool! Adding the ability for content hashes to be collected would be a great step to help ensure supply chains remain unaltered.

Perhaps extend your Stewfile to include a sha256 of the binary? you may want to consider some sort of registry to help prevent tampering (for example, newly installed binaries could trigger some automation to collect and save sha information into something you could look up against).