Packaging changes for 18.3.0

Binary path

Some changes have been made to the repo structure since 18.2 that may break builds for 18.3

In prior versions, the binary resided in /atuin. After some restructuring, it is now in /crates/atuin. This is because the root of the repo was getting pretty cluttered after introducing some more crates.

I had a quick look at the homebrew formula and the void template, and both will need adjustments. I’m assuming other repos will be affected.

Builds

I’ve been migrating our release workflows to use cargo-dist from axo.dev here: chore: switch to cargo dist for releases by ellie · Pull Request #2085 · atuinsh/atuin · GitHub

It’s much easier to build binaries for a variety of platforms this way, and having more of the process automated means I’ll be able to push releases more frequently.

Our install script has also caused issues. Often users want to know how Atuin was installed, and the answer of “probably your system package manager, maybe a deb, maybe cargo install” isn’t ideal.

The current script will use the system pkgman where it can, and falls back on cargo install when it can’t. To start, I’d like to replace the cargo install fallback with the cargo-dist install script. Instead of compiling from source, users will get a binary. This should make installs on slower systems much more pleasant. If all goes well, the install script may be entirely replaced with the cargo-dist installer.

Our docs can still highlight the package manager installs wherever possible, but provide a consistent experience from our own installer.

I’ll be testing this by pushing a prerelease in the next few days, in the same way as a weekly.

Speaking of packaging, do you intend to build Debian packages for future releases? I noticed that there’s no .deb file for the recent 18.3.0 release, maybe you just haven’t gotten to it yet?

In any case, thanks!

Hey! I should have written about that, sorry

I’m not planning on implementing any special builds for specific distros or package managers at this time, though if cargo-dist supports them in the future then it might happen.

I’d consider it if we’re breaking a lot of core workflows by removing debs, but I think the install script handles those cases well. I’d rather not spend any more time thinking about the specifics of various distros, and instead ensure we build binaries for as many platforms as possible

1 Like

Thanks for the quick reply! I did use the .deb file for the last release, but it’s really not a big problem to return to the install script.

And of course thanks for Atuin!

1 Like