Meaning of ${self} in flake changes when used as an input

I have a local git repo with flakes at ./a/b and ./c, both with a single package output.

The flake at ./c uses the other as an input with url "../a/b".

./a/b, as part of its build, copies a file from its directory to the unpacked source directory.

When running nix build on ./a/b the script command needs to be
cp ${self}/a/b/filename target

But when running nix build on ./c, the script fails unless it’s changed to
cp ${self}/filename target

Is this a bug of some sort?

1 Like

self is the flake itself. When used in an interpolation, it should be replaced by the root path of the flake in the store.

I do not really understand your folder structure and therefore will not comment on the remainder of the question.

1 Like

So after playing around a bit, I’m still confused… :joy:

What definitely works without altering the flake at ./a/b is using the following url in ./c/flake.nix:

git+file:///abs/path?dir=a/b

However, as soon as I try to get rid of the absolute path, I have problems:

git+file://..?dir=a/b
file+file://..?dir=a/b
both fail due to file: only accepting absolute paths (“has unexpected authority ‘…’”).

path:..?dir=a/b
fails because path apparently doesn’t like the dir paramter (“has unsupported parameter ‘dir’”)

..?dir=a/b
is highly confusing. The nix manual suggests this should be the right one to use (" If the directory is part of a Git repository, then the input will be treated as a git+file: URL"), but the dir parameter appears to be silently ignored, i.e. the flake in the root folder of the git repo is being used.

I’m gonna try to put together a minimal example of the issue.

[edit] Meanwhile based on this discussion I tried git+file:..?dir=a/b but got "could not find HEAD ref from repo at ‘file:…’ using ‘master’.

So it turns out git+file:.?dir=a/b (note the single dot) works, regardless of where the calling flake is inside the repo.

I still need to make a minimal example, because I think the behaviour of git+file:..?dir=x (with two dots) is incorrect.