Relative path support for Nix flakes

Help
1

As far as I’m aware, Nix Flakes should have had support for relative paths for a while now?

For some reason, when I nix develop in my project on a new Nix installation or after I run gc, I get this:
error: cannot fetch input 'path:../js-dependencys?narHash=sha256-cayhXT6eRBgQuvfu1IKkJpqdjKkhdzRKYsUikx%2fQo%2fY=' because it uses a relative path

Strangely, this goes away once I do flake update. What could be the cause of this annoying behaviour?

4 Likes
2

This comment in the issue probably explains it?

4 Likes
3

You seem quite right, thanks for your pointer!

1 Like
4

The linked github comment says:

Relative paths currently rely on a source with the correct hash to be already present in the store.
This is fragile but won’t be noticed by the flake author, because creating the lockfile adds locally

I take huge issue with this, it is certainly noticed by the author of the flake. How does one solve the problem? It seems I must first build the included flake before the encompassing flake? EDIT: No, that doesn’t fix the issue.

1 Like
5

If you build the included flake before the encompassing flake, it should work.

In the meantime I myself have resorted to workarounds of variously:

  • running nix commands in a wrapper that always passes --override-input
  • directly using import
2 Likes
6

I would want to achieve a single monorepo to develop multiple different projects and deploy them to servers using single flake.nix in the project root.

Would there be better workarounds in 2025?

Does directly using import look like something like this:

7

The issue was closed via PR:

Now relative path inputs are accessed via the accessor of the calling flake. This avoids the unnecessary copy and makes it possible for relative path inputs to depend on flakes in a parent directory.

Of course it’s not part of a release yet, so you’d have to use nix master or patch your nix with the contents of the PR.

2 Likes
8

There was a time that I was really keen on relative paths in inputs. The idea was that the parent flake or any of its children flakes would feel like a full fledged project, and the distinction between how the other stuff is sourced and tracked would be relegated to the format of whichever relevant input. Composability, yay.

After walking that path for a while it started feeling kind of awkward for reasons that have more to do with git than with nix. There are things like submodules and subtrees which you can use to nest git repos, but they always become yet another thing that devs are going to have to deal with. This added enough extra friction that I ultimately stopped chasing the parent/child flake idea.

I’m not saying that this will apply to anyone else, but FWIW I settled on letting what I previously thought of as a child flake just be a nix module, like so:

It feels to me a bit cleaner because you don’t have to harmonize the versions of nixpkgs with follows directives in the input but rather by just making pkgs be a parameter of the module.

On the other hand, here I have to implement myself what I’d get for free if I was leaning more heavily on flake.lock, so perhaps I’ll toy with relative path flakes a bit more once I’m using a version of nix that has them.

Edit, one year later: I got that version and toyed with it: GitHub - MatrixManAtYrService/hello-subflakes

2 Likes