@qyriad: Command-line usage does conceptually lock a flake even if it doesn't create a flake.lock file per se. For example:
$ nix flake metadata nixpkgs
Resolved URL: github:NixO…Do we intend to support the flake registry at all? The reason I'm asking is that the arguments you're making against indirect flake inputs seem to equally apply as reasons to drop the flake…
:write to nix repl
Can you elaborate a bit more on the use case for mirroring REPL commands to a file?
Part of the reason I'm asking is that many REPLs provide a .history file containing commands the user has…
Do you mean that we're grandfathering existing flake.nix files that use indirect flake inputs if they've already been locked in flake.lock, but we refuse to lock new indirect flake inputs…
Just to clarify: is this issue to ban indirect flake inputs entirely or just banning updating those inputs? The reason why is that the title sounds more like the former whereas the description…
Maybe still warn (just once, not per path) when using this fallback? The main reason I suggest this is that the user might not understand why their path is being built when they were expecting it…
nix does not propagate up to NixOS systems definitions
I don't think there is a bug here (or in other words, I believe things are working as intended). The reason you don't get a build failure is because the nixosTests.misc doesn't use pkgs.nix…