chore: switch to cargo dist for releases #2085
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Closed
|
I'd like to figure out how to update nix, but min rust versions can be dealt with elsewhere I'm going to merge this, and use it to ship a pre-release. We already have weekly releases, so this would be a pretty nice replacement for that Wrt the install script, after some thought I'd rather not totally replace it immediately. To begin with, we can use the cargo-dist installer as a fallback instead of cargo-install |
|
This pull request has been mentioned on Atuin Community. There might be relevant details there: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to see how CI behaves here before merging anything.
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. To start off, I think it would make sense to use this as a fallback instead of using cargo install
Historically, we have used the system package manager wherever possible.
Once 100% 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