atuin/rust-toolchain.toml

[toolchain]
channel = "1.80.1"
chore: switch to cargo dist for releases (#2085) * chore: switch to cargo dist for releases From https://axo.dev cargo-dist handles building releases far better than we can, and do so for several large projects now. We will need to change our install script to use the cargo-dist installer. Historically, we have used the system package manager wherever possible. Once switched to the new installer, this will no longer be the case. If the user wishes to use their package manager, and Atuin is maintained there, then they can choose to do so. This way, we can ensure that users are running a known build, can easily uninstall (just delete the atuin dir), easily update, etc. Builds will use our lockfile, and can have their checksum verified. Later, I'd like to introduce build signing. As Axo are focused on release engineering, they will likely have resolved many more issues than we have - libc versions, etc. I'm not particularly happy with our response of "just use your package manager", as many users seem to have difficulty there. It's unclear what our installer has done, as this behaviour varies massively across systems. It's also unclear how some package maintainers may have patched things I'm hoping that some better release tooling will lead to more confidence in the process, and therefore more frequent releases. Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529 * config * add protobuf * test build * use native arm mac * lol * add toolchain * use 1.78, 2vcpu * nix flake update * 1.77 2024-06-05 14:25:01 +02:00			`[toolchain]`
chore: update rust to `1.80.1` (#2362) fixes #2360 https://blog.rust-lang.org/2024/08/08/Rust-1.80.1.html `1.80.1` fixes a fairly nasty miscompilation, but that's not my motivation for opening this PR. If I'm understanding correctly, because the rust patch version was not specified in `rust-toolchain.toml`, nix automatically upgraded to the new version. This broke the hash in `flake.nix` causing the flake to fail to build. Making this upgrade to `1.80.1` explicit, fixes this issue. 2024-08-14 13:35:36 +02:00			`channel = "1.80.1"`