atuin
atuin copied to clipboard
Add support for installing binaries
As noted in a existing TODO, this installs the atuin
binary directly at /usr/local/bin
for operating systems that don't have an official method. For example: Raspberry Pi / MacOS (without homebrew).
Steps:
- Get latest release info to find out the version.
- Get the release archive and extract it to a temporary directory.
- Move the
atuin
binary to PATH.
This is based on the installation script for
sysit
- a small utility I made.
Also, add support for custom binary installation path. It can be an additional argument to the install command. For instance:
INSTALL_DIR=~/.local/bin bash <(curl https://raw.githubusercontent.com/ellie/atuin/main/install.sh)
to install the binary in ~/.local/bin
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
atuin-docs | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Dec 24, 2023 7:29am |
@ellie, made the suggested changes.
@ellie did you get a chance to look at it?
@crodjer looks like the prompt I mentioned in a previous review isn't here?
I think it would be good to
Let the user know what's going on (eg tell them we couldn't find anything + will install a binary from releases) Tell them where it's being installed, and ask for y/n to go ahead
I really don't want to go installing files on the users system without confirmation. It would be good to tell them what files are going to be downloaded where, and also explain how they can change that.
Also - the real fix for Ubuntu is to also build a deb for aarch64 and install with the proper tooling, not to install a binary manually. This should be a last resort.
looks like the prompt I mentioned in a previous review isn't here?
@ellie Yes, I figured we could rely on the sudo
call. But you are right, users may miss out on seeing the prompt if sudo authorization is cached. So, added an explicit prompt as well. It'll behave like this:
Will copy atuin binary to /usr/local/bin...
Okay? [Y/n]: Y
Downloading atuin v17.1.0 from the latest github release...
Copying atuin binary to /usr/local/bin ...
I didn't want an explicit prompt because it'll then affect my scripts. For that, I have added another environment variable: ATUIN_NO_PROMPT
. My goal toward having a binary install support was primarily to ensure my automation works on all my machines.
Longer term, I think the approach for installing binaries should be one of the following
- Use the users' package manager wherever possible
- Fallback to installing a binary to ~/.atuin or similar, request the user add to PATH
- Provide instructions for manual install to /usr/local/bin, ~/.local/bin, etc. These paths differ across distributions, platforms, and individual setups.
I am generally quite against automatically installing to known binary paths. This is the job of a package manager, and there are almost certainly many edge cases we have not considered. This can also conflict with existing package managers and other installs, which is not something we want.
Especially in the case of /usr/local/bin, I'd rather avoid calling sudo
(unless it's needed to call a package manager).
My goal toward having a binary install support was primarily to ensure my automation works on all my machines.
For this specific case, you should be able to use ansible/saltstack/etc to automate a manual binary install.
I understand. Lately I haven't been using atuin
, so I didn't ping further for review.
I discovered https://github.com/cargo-bins/cargo-binstall, so cargo binstall atuin
should be able to serve a similar use-case.
You might consider adding that as an option to the doc.