Allow non-flake local path for --override-input #4086
Conversation
The expected use case here is that a flake has been created for a third-party project that does not emplace the 'flake.nix' at in that project's top-level directory. Then the third-party project is checked out locally and so the flake.nix (living elsewhere) is being redirected to that local checkout: ``` $ nix build /local/path/to/flake.nix --override-input project /path/to/project ``` These tests ensure this type of input override works as expected.
Prior to this change, the only way to specify that an input was not a
flake was to use the 'flake = false;' as part of the attribute set
specifying that input. When using --override-input, it is not
possible to specify that path.
The use case is where a project is not (yet :-) nix-supporting and the
flake.nix has been developed and maintained separately. The
interesting subset of flake.nix is something like:
```
{
input.project = {
type = "github";
host = "github.com";
owner = "projowner";
repo = "project";
flake = false;
};
outputs = { project, ... }:
packages.x86_64-linux = {
project = stdenv.mkDerivation {
src = project;
...
};
};
}
```
The above works fine, but if the project is checked out locally to be
worked on, the user should be able to do something like:
```
$ nix build /path/to/flake.nix --override-input /local/project/checkout
```
This patch makes this type of override possible (prior to this patch
it would fail because `/local/project/checkout` doesn't contain a
`flake.nix` file).
Note that simply adding the `false` argument (for `allowMissing`) to
the handler for `--override-input` is sufficient to get the above
working, but it also disables treatment of the input as a flake if it
is one. This change includes logic that examines the input location
to determine if a `flake.nix` is present and treats it accordingly.
The `isFlake` flag in `FlakeInput` is still applied for the
inheritance cases that previously existed, but when the `FlakeInput`
is dynamically constructed from a `FlakeRef`, the target of the
fetched `FlakeRef` is used to make the "is a flake?" determination.
|
This is ready for review @edolstra and would be good get merged to fix flake support for |
|
Does this fix #3779? I don't know the Nix codebase well enough to understand the code, but it looks like the test case indicates it might? (Context: Currently there is no way to use |
|
This does not fix #3779 as I understand it: this PR does not change the stance of flake.lock updates based on command-line @edolstra , I updated this from master to resolve the merge conflict, so it's in mergeable state again. |
|
I also desire this. @edolstra by self assigning this, do you mean you're going to implement it yourself elsewhere? Edit: fwiw, no response will indicate a yes |
|
Re-synchronized changes with master again, ready for merging, @edolstra . |
|
AIUI when he blanks you like this it's cause he either doesn't care or he's going to do it better himself |
|
Or just busy with other work. |
|
I marked this as stale due to inactivity. → More info |
|
This is still needed AFAICT? |
Very much so. |
|
So I’ve spent a bit of time trying to merge this with master to review it (there’s quite a bunch of conflicts :( ), only to realize that as far as I can tell, the underlying issue is already fixed in master (and apparently by me 🤦♂️ ). So I’ll close this. That being said,
@kquick , do you think you could open a couple of PRs for just these? |
|
(just ftr, the manual test I ran to make sure that it was indeed working on master was: $ cat <<EOF > flake.nix
{
inputs.foo = {
url = "path:./a";
flake = false;
};
outputs = { self, foo }: {
foo = builtins.readFile "\${foo}/foo";
};
}
EOF
$ mkdir -p a && echo a > a/foo
$ mkdir -p b && echo b > b/foo
$ nix eval .#foo
"a\n"
$ nix eval .#foo --override-input foo $PWD/b
warning: not writing modified lock file of flake 'path:/tmp/tmp.HB372FSu5F':
• Updated input 'foo':
'path:./a?lastModified=1&narHash=sha256-Nep3gAa7Eq4+Dv9plpoqx%2f+AJ+gWeV7U9lEiGCPRrR4=' (1970-01-01)
→ 'path:/tmp/tmp.HB372FSu5F/b?lastModified=1652775844&narHash=sha256-lGQM58%2frdQGqiOUqjGIYvo4nwaoVuGFnFx813YbaA5Y=' (2022-05-17)
"b\n") |
|
FWIW this still doesn't work for me |
Mh strange 🤔 Is the exact repro I sent broken or are you doing something slightly different? I just noticed that @colemickens mentioned some time ago that my fix was broken, so maybe it just works under some very specific conditions |
This PR makes it possible to use --override-input for non-flake inputs as well as flake inputs. See 40968dc for a full description of the main change in this PR.