CppNix compat: path literals in flake inputs #1140

New issue

Open

opened 2026-02-24 14:11:12 +00:00 by goldstein · 3 comments

goldstein commented

2026-02-24 14:11:12 +00:00

Member

CppNix added a feature a while ago that allows path literals in .input.url, like so:

# flake.nix
{
  inputs.a.url = ./a;
  outputs = _: {};
}
# a/flake.nix
{
  outputs = _: {};
}

relevant commit: github.com/NixOS/nix@3180671cab

Describe the solution you'd like

we could port this feature to Lix

Describe alternatives you've considered

we could avoid doing that. this is a compat wrinkle, but there’s a workaround of writing "path:" strings (although it’s a bit harder if an incompatible flake is in your (transitive) dependencies)

Additional context

I found this during a crater-like test run. I’ve seen a single repo that uses this in the wild, but there might be others.

I’m aware that flakes are currently frozen; this could be implemented after they thaw.

I can work on porting this patch if this is accepted.

## Is your feature request related to a problem? Please describe. CppNix added a feature a while ago that allows path literals in `.input.url`, like so: ```nix # flake.nix { inputs.a.url = ./a; outputs = _: {}; } # a/flake.nix { outputs = _: {}; } ``` relevant commit: https://github.com/NixOS/nix/commit/3180671cabeb6a6010057770731e12761ed5666c ## Describe the solution you'd like we could port this feature to Lix ## Describe alternatives you've considered we could avoid doing that. this is a compat wrinkle, but there’s a workaround of writing `"path:"` strings (although it’s a bit harder if an incompatible flake is in your (transitive) dependencies) ## Additional context I found this during a crater-like test run. I’ve seen a single repo that uses this in the wild, but there might be others. I’m aware that flakes are currently frozen; this could be implemented after they thaw. I can work on porting this patch if this is accepted.

goldstein added the

Area/flakes

label

2026-02-24 14:11:16 +00:00

raito commented

2026-03-03 02:45:29 +00:00

Owner

If we allow that syntax element in the input, what about ${./a} ? Should this be allowed?

If we allow that syntax element in the input, what about `${./a}` ? Should this be allowed?

goldstein commented

2026-03-03 10:02:40 +00:00

Author

Member

(assuming you mean "${./a}"), my intuition is “no”, because it’s unclear why would anyone write this and it requires more evaluation than is usually allowed in flake inputs.

// I’m personally of the opinion that flake inputs should allow arbitrary evaluation, but that’s a very different discussion

as a data point, CppNix currently disallows it specifically because it requires too much evaluation (the message is expected a string or a path but got a thunk)

(assuming you mean `"${./a}"`), my intuition is “no”, because it’s unclear why would anyone write this and it requires more evaluation than is usually allowed in flake inputs. // I’m personally of the opinion that flake inputs should allow arbitrary evaluation, but that’s a very different discussion as a data point, CppNix currently disallows it specifically because it requires too much evaluation (the message is `expected a string or a path but got a thunk`)

qyriad added the

Context

RFD

Language/C++

labels

2026-03-08 14:30:23 +00:00

cassandracomar commented

2026-07-07 15:19:51 +00:00

the path: workaround leads to different, incompatible lockfiles between lix and CppNix. I think the issue is that nix treats a path:relative/path/ the same way it treats a bare ./relative/path, leading it to produce a lockfile incompatible with lix. the error is:

error:
       … while updating the lock file of flake 'git+file:///path/to/flake'

       error: lock file contains mutable lock '{"path":"./dir","type":"path"}'

CppNix, on the other hand, treats the lix-produced lockfile as stale, and immediately updates it to the broken format. this means the flake provider has to use lix to manage the lockfile or do something else entirely (like move the relative path input to a separate repo).

the `path:` workaround leads to different, [incompatible lockfiles](https://github.com/marienz/nix-doom-emacs-unstraightened/issues/133#issuecomment-4905171059) between lix and CppNix. I think the issue is that nix treats a `path:relative/path/` the same way it treats a bare `./relative/path`, leading it to produce a lockfile incompatible with lix. the error is: ``` error: … while updating the lock file of flake 'git+file:///path/to/flake' error: lock file contains mutable lock '{"path":"./dir","type":"path"}' ``` CppNix, on the other hand, treats the lix-produced lockfile as stale, and immediately updates it to the broken format. this means the flake provider has to use lix to manage the lockfile or do something else entirely (like move the relative path input to a separate repo).