Resolve //path to flake root

[msanft]

Is your feature request related to a problem?

Users of flakes in repositories with somewhat-nested tree layouts often get into positions where they have to:

import ../../../../foo.nix

This is error-prone. For example, if foo.nix gets moved around, it's easy to add a ../ too much, causing errors.
Furthermore, this is very much not nice to look at.

Proposed solution

Resolve a path of form //path to the flake's root directory. If I have a flake.nix in /home/me/my-project/flake.nix, and the project layout is as follows:

• /home/me/my-project/foo/bar.nix:
  • "foo"
• /home/me/my-project/some/deeply/nested/tree/package.nix:
  • import //foo/bar.nix

Evaluating /home/me/my-project/some/deeply/nested/tree/package.nix should return "foo".

Alternative solutions

Passing self around should work, but having a short-hand path operation for this would be nice.

Additional context

Checklist

• checked latest Nix manual (source)
• checked open feature issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[roberth]

I'm not entirely convinced that we need this. (Excuse my ignorance)

It might be symptomatic of a lacking attrset-based structure, which doesn't scale well beyond a few function calls, because you're not benefiting from the implicit memoization that attrsets like the packages output attribute provide. (We do implicitly memoize files' top level values, but that's inconsequential for most files, which contain functions)

In my experience, relative references tend to be replaced by references not necessarily to self but to attributes with in it, or in some other fixpoint, like mkScope, or config in flake-parts.

mkScope/callPackage example:

nix/src/nix/package.nix

Lines 5 to 8 in 3f3feae

	, nix-store
	, nix-expr
	, nix-main
	, nix-cmd

What should the behavior be for subflakes?

if foo.nix gets moved around

In my opinion, we should use content aware tools that do this kind of thing automatically.
This feature only solves half of the problem, and makes expressions prone to the inverse problem: when you move a subtree with internal references, you'll have to update the // paths to refer to the new location of the subtree. This wouldn't be necessary if the paths were relative.

[roberth]

Implementing this as proposed would be a breaking change to the expression language, because it changes the interpretation of

nix-repl> foo = { bar = true; }

nix-repl> { } //foo
{ bar = true; }

It also makes the following ambiguous - either:

nix-repl> { __functor = self: arg: arg + "/bar"; } //foo
//foo/bar

or

nix-repl> { __functor = self: arg: arg + "/bar"; } //foo
{ __functor = <...>; bar = true; }

[msanft]

Thanks for your replies @roberth!

This feature only solves half of the problem, and makes expressions prone to the inverse problem: when you move a subtree with internal references, you'll have to update the // paths to refer to the new location of the subtree. This wouldn't be necessary if the paths were relative.

That's definitely a fair point I didn't consider very much so far. In general, my suggestion was very much tied to the one-flake structure.

Implementing this as proposed would be a breaking change to the expression language

Oopsie! I didn't consider this case as well. For me, that's definitely outweighing the benefits of such a shorthand.

Considering the points you've made, if you wouldn't object to it, I'd close this issue then.

[roberth]

No problem. I have to say I quite liked the idea at first, but it doesn't seem to be a great fit.
We could consider it again if/when we have language versioning.