flakelight
flakelight copied to clipboard
Automatic reading of `flake.lock` makes `--override-input` not work
I spent a long time trying to figure out why the Nix option --override-input didn't work. I even thought this was a bug in Nix, and tried various different Nix versions. Finally I found that flakelight sets the inputs option (which also gets passed around as module args here and there) by explicitly reading flake.lock, bypassing anything that --override-input specifies. This was super-confusing and wasted a lot of time.
In the end, the workaround was simple, just inherit inputs as suggested in https://github.com/nix-community/flakelight/blob/master/API_GUIDE.md#inputs. However, nowhere is it mentioned that by default, --override-inputs does not work with flakelight.
Can this default behavior be changed, or at least clearly documented?
Rather than a workaround, that is intended behavior. Unless inputs is passed to flakelight, it can't get the defaults otherwise, which is why with other libraries, passing inputs is required. So if inputs are passed, they are used, and everything is the usual. It only uses the values from flake.lock if inputs are not passed in.
I'll add a note about --override-input to the docs
Can this default behavior be changed, or at least clearly documented?
Re-reading my issue report, I think this comes off a bit strong. I apologize. You have clearly put much thought into flakelight, and I really appreciate it. I'm just a little bit puzzled, is --override-input not something you commonly use? I use it all the time, so I would never find the default flakelight behavior useful.
For config repos where messing with Nix stuff is the point, I find --override-input occasionally useful for testing unreleased input versions, but most of the flakes I write are one-offs for small projects or dev environments, where you just need nixpkgs or some compiler flake. I'd not noticed that --override-input doesn't work without passing inputs, since in the only flake I use --override-input, I pass inputs.
Rather than loading the flake.lock, the other behavior (as it was previously) is to just not set the values.
So to consider the cases, we could be passing inputs or not, and using inputs or not
- if passing inputs, and using them, same either way
- if passing inputs, and not using them, same either way
- if not passing inputs, and not using them, same either way
- if not passing inputs, and using them, without the feature you get an error, with the feature it pulls from your flake.lock (what was likely intended)
One exception is nixpkgs, which otherwise defaults to flakelight's nixpkgs, but having nixpkgs in your lock and still wanting to use flakelight's does not seem likely.
So going by above, adding this is just adding additional functionality, and flakelights goal is to lower boilerplate and do what user intended, so fit as a good add.
I agree that for flakes where --override-input is likely to be used, and stuff like flakes with lots of inputs, its preferable to pass inputs as you would be forced to do before. The documentation does not make this clear, I agree. I'll make that more clear.
I'll probably add some templates too for a good starting point for various type of repos.
Below, I've pasted the message I'd posted on the Matrix channel (#flakelight:nixos.org) before I'd added that ability:
I'd like to float an idea.
If you just want flakelight to provide you a recent nixpkgs (the default), you dont have to do anything:
{ inputs.flakelight.url = "github:nix-community/flakelight"; outputs = { flakelight, ... }: flakelight ./. { }; }If you want to bring your own nixpkgs, you have to pass it to flakelight:
{ inputs = { nixpkgs.url = "nixpkgs/nixos-unstable"; flakelight.url = "github:nix-community/flakelight"; }; outputs = { flakelight, ... }@inputs: flakelight ./. { inherit inputs; }; }But what if you didn't have to pass it and flakelight would use your input?
Like this:
{ inputs = { nixpkgs.url = "nixpkgs/nixos-unstable"; flakelight.url = "github:nix-community/flakelight"; }; outputs = { flakelight, ... }: flakelight ./. { }; }Currently, that is having a nixpkgs input, but having flakelight still use its default.
With this proposal, that becomes using your nixpkgs input for flakelight as well.
Upsides:
- Easier to just override inputs
- current behavior might confuse people?
- Less boilerplate
Downsides:
- Someone might intentionally want to have a nixpkgs input but still have flakelight use the default (seems unlikely).
- Maybe small perf impact as have to read flake lock?
Passing inputs explicitly may still be preferred for performance or unusual circumstances, so of course passed inputs override detected ones. It would also need to be passed if one wishes to pass inputs and the path passed is not
./..(The autodetection would work by reading
./flake.lock, which is why if the path passed is not the usual./., it can't autodetect.)
Added a note to the docs. Will also add some templates.