Releases contain un-updated `Cargo.lock` file

[AngerM]

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:

1. Install sniprun using your favorite package manager (ex: Lazy.nvim)
2. Wait for the next update to be released
3. Package manager will fail to update since git pull fails

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",

[michaelb]

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

[michaelb]

I'll push an updated cargo.lock in the meantime, this should fix your immediate issue, please confirm

[AngerM]

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

[michaelb]

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

[michaelb]

could you check your issue is gone ? I should have pushed a new commit to master

[AngerM]

$ 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!

[michaelb]

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

[pysan3]

@michaelb Thanks for the note.

It looks like the latest release on github is still v1.3.7 which is affected with this issue.

I use lazy and only download the latest release (not the latest main branch).

Would you kindly release a new version that contains your fix (I suppose https://github.com/michaelb/sniprun/commit/1c152ee5d883db7233e3891012bc4f0f9437a82b ?)

[michaelb]

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

[michaelb]

@pysan3 a new version (v1.3.8) just got released ! I'll close this issue some time from now, assuming no activity means no complaints !