npins: 0.2.4 -> 0.3.0

[herbetom]

Changelog: https://github.com/andir/npins/releases/tag/0.3.0

I used the following steps to update npins:

nix-build -A npins
./result/bin/npins -d pkgs/by-name/np/npins/ update
nano pkgs/by-name/np/npins/package.nix # empty cargoHash
nix-build -A npins
nano pkgs/by-name/np/npins/package.nix # set cargoHash
nix-build -A npins
./result/bin/npins -d pkgs/by-name/np/npins/ init
./result/bin/npins -d pkgs/by-name/np/npins/ upgrade
rm pkgs/by-name/np/npins/default.nix
nix-build -A npins

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[piegamesde]

Technically, you'd have to update the sources.nix as well. Though OTOH, that idea is dead and might as well be removed altogether

[herbetom]

Yeah, i was a bit suprised to even find that there.

[piegamesde]

I still am convinced that putting hashes out of the code into a machine readable format is superior to having to mokey-patch Nix expressions with find and replace or static analysis, but as this PR clearly shows most applications have more hashes to pin than just the sources which kind of defeats the point. Attempts to fix this were not fruitful, so I eventually abandoned that idea

[nixpkgs-ci]

Backport failed for release-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.11
git worktree add -d .worktree/backport-389960-to-release-24.11 origin/release-24.11
cd .worktree/backport-389960-to-release-24.11
git switch --create backport-389960-to-release-24.11
git cherry-pick -x 7803dc04a1761490eafc995093e1d944bd8f93bd

[nixpkgs-ci]

Backport failed for release-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.11
git worktree add -d .worktree/backport-389960-to-release-24.11 origin/release-24.11
cd .worktree/backport-389960-to-release-24.11
git switch --create backport-389960-to-release-24.11
git cherry-pick -x 7803dc04a1761490eafc995093e1d944bd8f93bd

[piegamesde]

Are you sure this fits the backporting guidelines?

[Scrumplex]

It didn't seem like there are any breaking changes in the changelog :O

[piegamesde]

I bumped the minor version, which according to SemVer allows for breaking changes, because I simply can't guarantee the absence of breaking behavior changes. Especially since this is a CLI application and I am unsure what exactly the version compatibility contract entails. Especially, the CLI parser had a major bump and the order and scope of some flags has changed, which might result in constellations where a command wouldn't run anymore with the update.

I'm not strictly against a backport btw, just uncertain as to how strict our policies are