Cut a new release? about sniprun

[michaelb]

Makes sense, but while I agree that it's my fault for accidentally not following the best practices, I can't possibly be expected to respond to distribution-related issues in each and every package manager.

For example, I'm aware that several patches have be made to have sniprun work on NixOS due to its specificities: https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/editors/vim/plugins/patches/sniprun/fix-paths.patch, and I would have been quite unable to provide these myself.

Generally speaking, sniprun does not need a commited cargo.lock to work, as shown by its (accidental) absence that went unnoticed for quite long, so I won't take it as a major 'break' of the project.

I'll fix that issue when I have enough actual fixes/features to warrant a new release, in the meantime, feel free to stay on an older version of sniprun where the cargo.lock was still in git. You're not missing on a lot of things, to be honest

[michaelb]

Well spotted.

It's a minor error that occured a few releases ago actually. Since it's ok for rust packages not to commit Cargo.lock files (most often for libraries, and not binaries like sniprun, ok), and that sniprun has its dependencies fixed tight enough in Cargo.toml that I'm confident from those (and my experience) that no dependencies update will break sniprun, I don't think I'll release a new version just for that

[figsoda]

For nixpkgs we require a Cargo.lock present in the source for reproducibility reasons, so we are having to patch in the Cargo.lock for the package to be updated