mccA piece of Rust software I maintain just got a PR attempting to check in a flake.nix and flake.lock. Is this normal, for a Rust package? Do I actually have to put them at in root directory? Is the implication I'd need a flake.guix and guix.lock up there eventually as well? I really hate how modern packaging means like 18 files named like rollup.config.js cluttering the root directory and confusing anyone who just landed on the github page.
Zoe : Void -> a@mcc to channel Mitch Hedburg, "this repo has a flake.lock, which means... it's outdated"
@mcc I think it applies to lock files generally. If it's not actively being used, the dependencies will likely be outdated by the next time anytime actually tries using it. I've found that to be the case with both pesonal projects and auxiliary projects at work with aren't tired into our main CI infra.
@zmz Oh, so it's not that use of a lockfile indicates an outdated version of nix, but rather that using a lockfile guarantees outdated dependencies.
But my experience with Rust/JS is that if you *don't* use a lockfile, you're at extreme risk of updating versions to an incompatible set and the project not building at all?
@mcc sorry, I'm tired and I don't think I'm communicating well today. Lock files are fine, but they need maintenance. The cargo.lock is in the critical path for building the project, so maintaining it is a natural part of maintaining the project, but the flake.lock isn't, so it's more likely to be neglected.
@mcc nix flakes are also more of a maintenance pain in my experience then other kinds of lock files, because most of the deps are going to be from the nixpkgs pin, which makes it hard to get specific versions of dependencies of there is an incompatibility
Aiden Fox Ivey