I’m curious if anyone is working on making *.lock files accessible to non-flake nix? Just like the fetchTree feature got “cherry picked”, is there an RFC or WC or even just thread somewhere on doing the same for *.lock files? My subpar google skills are failing me, curious if anyone here knows.
1 Like
It’s fairly doable with vanilla Nix. That’s what flake-compat is.
1 Like
I was hoping for something a little more streamlined, particularly:
- some kind of integration with builtins (either with b.fetchTree and/or another function)
- the same “update the lockfile when run with missing inputs” semantics as flake.lock
- the ability to update all inputs in the lockfile
- maybe even: full and automatic compatibility with existing flake.lock (and/or devshell.lock?) files
And also curious if that would be the opportunity to discuss things that are not in flakes but might be desirable:
- semver
- lazy fetching of inputs
- …?
I currently also use a two-step workflow with explicitly defined inputs in a flake.nix, which exports its outputs, which are then consumed by a default.nix which uses flake-compat, but the devex is, shall we say… “unpolished” 
curious what others think.
edit: to clarify: I am currently in the information / inspiration gathering phase, more so than in the “proposal” phase. I think the limits of my creativity will prove too low for a coherent proposal so I’m actually curious if there’s existing literature on this specific subject. I’m sure people are aware that lockfiles are among flakes’ most popular features, and I’m wondering whether there’s been talk of stabilizing that feature individually, regardless of the rest of flakes. Maybe there was, and it was rejected for a bunch of reasons I can’t think of now–that would also be very interesting to read.
The current .lock format is quite flakes-specific and contains some bad design choices, so I wouldn’t adopt it for other purposes at this stage.
In particular, Reuse input lock files · Issue #7730 · NixOS/nix · GitHub will solve some problems, and allow for a more efficient lock file, especially when the ecosystem fully supports the new format.
The Nix team is gradually bringing fetchTree into a shape where it can be marked stable, among other things. (related are incremental efforts to bring the good parts of “lazy trees” into Nix proper)
There’s also a spec project that has yet to really start: GitHub - nix-community/fetchTree-spec: A thorough specification and conformance suite for builtins.fetchTree and lock file items [maintainer=@roberth,@flokli,@lf-]. It’s mostly a few issues at this time - feel free to participate!
4 Likes
If you’re open to 3rd party solutions, there’s npins and nvfetcher. They aren’t compatible with flake.lock (I don’t know what devshell.lock is) but they at least provide their own locking and updates. nvfetcher allows for more constraints on updates, but it uses builtin fetchers (which is a bad thing, by the way, as nix eval is single-threaded, so you are choking eval). npins uses nixpkgs fetchers, but it double-fetches on the machine that you bump the lockfile on (this is a nix bug, ultimately) - however you do get the benefit of using a nixpkgs fetcher on any other machine. It’s also a bit lacking in terms of types of supported sources. I also know of niv, the precursor to npins, though I can’t think of a reason to use it now that npins exists.
If you care about the other features of flakes (pure eval, consistency in public API for your projects, etc.) then I think there’s no alternative to flakes at the moment.
TLDR there’s some alternatives that are hobbled by nix’s design flaws, pick your poison
I don’t think so? I think it uses builtin fetchers
I have no idea what this is about.
You’re right, I had them backwards somehow. In that case, I can’t think of a major downside of nvfetcher? (Though I haven’t used it enough to know.)
Thanks this is perfect. I’ll have a look, see if I can contribute anything.
@waffle8946 I meant devenv.lock not devshell–keep getting them mixed up.