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.
Badly-read literary snob@mcc I do use Nix and I would suggest rejecting it unless the author is willing to maintain it
✧✦Catherine✦✧@whitequark @RosaCtrl Well I was thinking about keeping it in a branch, so that if it grew out of sync I could periodically bump it.
Charlotte 
/Cinny 
@mcc @whitequark @RosaCtrl for what it’s worth you can also package rust applications on nix without adding files to the original repo, it is just more convenient if you are actively developing on nix
@mcc @RosaCtrl @whitequark (which is to say that if neither you or other major contributors use nix for development it’s probably just gonna be a maintenance headache)
Niklas Korz
Joe@mcc Someone did this to a Haskell project that I maintain, and I didn't merge it, but have kept the PR open and have also found it useful to refer back to
🆘Bill Cole 🇺🇦@mcc System-specific files should be the responsibility of the people maintaining that system's package. If you're not distributing a "flake" then it's BS for some random Nix user to ask you to include those files.
@grumpybozo well, i might prefer to maintain them, or at least have approval authority on them, so that the external maintainer doesn't sneak in a bitcoin miner or something
although for that to be useful i'd have to be able to read a flake file, which i currently can't
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
наб
Henri
Andre Weissflog@mcc so the same issue like people wanting to add cmake (or other build system files) to random C/C++ projects.
I would reject it. A package management system or build system should be able to work "non-intrusively" (for instance by creating a wrapper git repo which references the original project's git repo as submodule).
@mcc ...and I tend to mix up package- and dependency-management ;)
(but oth, npm dependencies are called 'packages', and the dependency download system in the Zig build system is also called 'package manager' - tbh I'd rather call the Linux system package managers something else...)
PunnO)))