Releases contain un-updated `Cargo.lock` file
AngerM opened this issue · 10 comments
Describe the bug
The updated releases contain an un-updated Cargo.lock file. This means when you do the sh install.sh or cargo build -r the Cargo.lock file is modified, which prevents future git pull's from succeeding with an error like:
Your local changes to the following files would be overwritten by checkout:
Cargo.lock
To Reproduce
Steps to reproduce the behavior:
- Install sniprun using your favorite package manager (ex: Lazy.nvim)
- Wait for the next update to be released
- Package manager will fail to update since
git pullfails
Expected behavior
The Cargo.lock file should be up to date, so cargo build -r does not modify it
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:
- Neovim version v0.9.2
- MacOS Sonoma
Additional context
The sniprun folder after installing the latest 1.3.7 update and doing the install:
$ git diff
diff --git a/Cargo.lock b/Cargo.lock
index 3503afe..c5ba1de 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -812,7 +812,7 @@ checksum = "942b4a808e05215192e39f4ab80813e599068285906cc91aa64f923db842bd5a"
[[package]]
name = "sniprun"
-version = "1.3.7-beta"
+version = "1.3.7"
dependencies = [
"close_fds",
"dirs",
Thanks a lot for the report. This is indeed a serious issue.
Cargo.lock has been a troublemaker for quite some time now, because of my trying to stay compatible with previous Rust versions (so can't update it, otherwise new libraries that liberally change their MSRV break mine). But then sniprun's own version inside cargo.lock doesn't change anymore !!
I think my solution is to not check-in Cargo.lock, what do you think about it?
Hopefully, users that use sh install.sh (no argument -> download, instead of compiling locally) shouldn't be affected
I'll push an updated cargo.lock in the meantime, this should fix your immediate issue, please confirm
In general, I think the "right" thing to do is push the updated Cargo.lock file, but I'm not super familiar with the Rust Ecosystem.
https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
https://users.rust-lang.org/t/how-to-distribute-rust-binaries/78400
As a general rule of thumb, yes
I wonder if I can just update sniprun's version in cargo.lock without updating other libs (potentially breaking my MSRV)...
turns out that yes!
cargo update --offline
could you check your issue is gone ? I should have pushed a new commit to master
$ git reset --hard HEAD
$ git pull origin master
$ ./install.sh
$ git status
HEAD detached from 3b31770
Untracked files:
(use "git add <file>..." to include in what will be committed)
doc/tags
nothing added to commit but untracked files present (use "git add" to track)
looks like it!
hmmm this wouldn't reproduce the original issue I think
But nevermind, I was able to test on my machine and ... people in your case (those who updated between 1.3.7's release and now) will still have the problem, and there's nothing I can do, sadly :-/
Hopefully there ain't many of them
@AngerM thanks for the feedback, it's really worth a lot!
PS: if you're on MacOS, you shouldn't ./install.sh since this will download the github-action-built binary that won't work. install.sh 1 or cargo build --release instead.
For people looking for a fix
I will keep this issue open a while so folks can find the solution: either
- remove / clean sniprun (then reinstall) from your package manager
or - go to wherever sniprun's saved (by your package manager) and
git reset --hard
Oh, you're right
I forgot (or lazily dismissed) the fact that not everyone pulls the latest master and some may have fixed a tag/commit in their package manager.
The next release is already scheduled for the coming days, thankfully