The convenience setup script is great, but it runs sudo to gain root access.
That’s a big no-no in ‘my book’, and I guess in other’s as well.
I don’t see a problem of running system-wide installation if the script detects it is running as root, but if not running as admin, there should be a user-level installation process.
I would recommend changing to the Webi mechanism instead, it should also simplify the setup a bit.
With atuin being a single rust executable, this should be rather easy to manage.
I’ll be happy to take a stab at this, if there is no objection by the maintainer.
I’d actually argue the opposite - generally it’s preferable for a script to ask for root if/when required, and you can audit the script to confirm this is the case.
Otherwise, we’d be suggesting to users that they pipe curl → sudo bash - imo this is a far bigger no-no.
At this time, I’d rather we didn’t manage our own binary install at all, and defer to package managers that people already have wherever possible. This also ensures most installs are kept up to date.
The script as-is can defer to user-level install. Eg, using cargo.
I understand the hesitation of not wanting to maintain an installer when so many package managers exist.
But keep in mind that when you update the repo’s binary release, it takes time until the package managers pull the change and propagate to their repositories. So the most updated package is always the one you produce.
brew and nix - provide ‘user level’ install options, although none are ‘recommended’ by their maintainers - as they advocate for their daemon based solutions.
cargo install, isn’t an easy install compared to just downloading the single binary which is all that is actually needed to run atuin is the binary.
Adding the atuin init output to the .profile/.bashrc/.zshrc are needed either way.
If you don’t object, I’ll try tackling a webi installer, and submit the PR there, if this works out, you’ll be able to decide whether to mention it in the documentation or not.
99% of Atuin users use Mac, and homebrew automatically updates within minutes. Usually, it’s on all major distributions within a day or two. I understand the thought there, but it’s not worth it for slightly fresher packages. I track the rollout quite closely where possible, and so far have been happy with it.
I wouldn’t say outlier, just not the majority of the userbase. This is still the case:
I would totally understand if the package maintainers were slow to push updates, but with all the repositories we are in right now they do a fantastic job of getting updates out. We’re looking to sort a PPA for Ubuntu/Debian.
There are some gaps in Linux distributions, but I’d rather we work to get atuin supported rather than just maintain our own install.
As a Linux user, I’d prefer that binaries are installed via the package manager wherever possible
We have to think of two priorities
Ensure it is easy for people to install Atuin
Ensure users stay up to date
(2) is critical
Our own binary install could be on the cards for the future, but I’d like to sort auto updating at the very least. It’s not a priority or an issue right now
Take a look at how chezmoi does it. It’s golang and not rust, so mechanism will differ for sure.
Also, atuin already reaches out to the network for sync, so checking whether an update exist, isn’t really introducing new libraries. Auto updating though, that’s a whole new challenge for sure.
) I’m the outlier.