You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
make regenerate-nix and niv update are fundamentally different commands.
make regenerate-nix converts the existing Cargo/etc lockfiles into Nix. It's idempotent, and exists to bring them back into sync. It will not update anything by itself. This is fine to do automatically.
niv update is like cargo update, it brings in whatever the latest version is of each (Niv) dependency. It should only be done with explicit user permission.
Yeah I understand that, but want to find a way to lower the burden on the developers.
We currently sometimes do cargo update, but much less frequently do we run niv update. Not necessarily a bad thing if the currently pinned niv packages work, but if we update more frequently we would likely pull in security updates (or, y'know, zero-days 🙃).
I think at minimum, I'd like to have CI (and pre-commit hooks) check that Cargo.nix is in line with Cargo.lock. We can work out the niv update process separately (I agree it should be intentional, but just done a bit more regularly).
Currently, the nix lock files (for crate2nix and for the packages via
niv
) are only updated when one of the Nix users runs:make regenerate-nix
, andniv update
This means that dependencies in Cargo.lock and Cargo.nix might be at different versions.
To resolve this, we can:
Optionally, perhaps
make regenerate-nix
could also do theniv update
so there is one command.The text was updated successfully, but these errors were encountered: