bug: Breakage from changed checkout due to flake path: prefix.

[galenhuntington]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

The PR #3646 appears to have changed how a repo is checked out. Formerly, the entire repo in which the flake lived would be copied into /nix/store/*-source/. (This feature, by the way, surprised me at first and induced me to move my Nix config into its own repo so as to not grab other material I was keeping under revision control.)

After the last commit, the checkout only happens relative to the directory the flake is in, rather than the entire repo. I currently have the flake files and expressions in their own directory, with my home.nix having references such as ../programs/foobar to pull in other system files and programs. These relative paths now error out with error: access to absolute path '***' is forbidden in pure eval mode (use '--impure' to override). Note that, contrary to the error, --impure won't work either since it points to the /nix/ directory rather than the files, so the messaging here is also wrong (but perhaps out of scope).

This can be worked around. The directory tree can be rearranged. And perhaps it's best practice to have flake.nix in the repo root. But it seems to be a major breaking change which should at least be announced.

Maintainer CC

No response

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.4.0-150-generic, Ubuntu, 18.04.6 LTS (Bionic Beaver), nobuild`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`

[dongcarl]

I'm the author of #3646, w/re this I have a few thoughts:

1. The immediate solution is: home-manager switch --flake git+file:///$HOME/.config/home-manager
2. The best solution is for upstream (nix itself) to adopt the following flake resolution logic:
   1. When a flake URL's type field is not specified (e.g. nix build /path/to/flake), try to see if it is a git repository first (e.g. if /path/to/flake/.git exists), if so, use git+file:///path/to/flake as the effective URL
   2. If not, try to see if /path/to/flake/flake.nix exists, if so, use path:/path/to/flake as the effective URL
   3. If still not (the git repo might be a parent of /path/to/flake), use git+file:///path/to/flake as the effective URL This will allow us to revert #3646 and have all the cases still work fine

I opened https://github.com/NixOS/nix/issues/8710 upstream for this

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[NobbZ]

@dongcarl This is exactly nix' behaviour, with searching upwards for the repo root.

[NobbZ]

In my opinion HMs behaviour of forcing path is a bug and the fact that it behaves different from "raw" nix violates the principle of the least surprise.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[ian-h-chamberlain]

In my opinion HMs behaviour of forcing path is a bug and the fact that it behaves different from "raw" nix violates the principle of the least surprise.

Agreed, I was indeed surprised to run into this issue; I have a layout like so:

/Users/ianchamberlain/.config
├── .git
├── flake.nix
└── home-manager
    ├── flake.nix -> ../flake.nix
    ├── home.nix
    ├── macos-defaults
    │   ├── keyboard-shortcuts.nix
    │   ├── personal.nix
    │   └── work.nix
    └── macos-defaults.nix

My .config directory has a bunch of other (git-untracked) files, some of which cannot be copied to the store, so without an explicit git+file:// argument, I can't use the default flake handling:

$ home-manager build --no-out-link 
error (ignored): error: reached end of FramedSource
error:
       … while fetching the input 'path:/Users/ianchamberlain/.config'

       error: file '/Users/ianchamberlain/.config/deluge/ipc/deluge-gtk' has an unsupported type
error (ignored): error: reached end of FramedSource
error:
       … while fetching the input 'path:/Users/ianchamberlain/.config'

       error: file '/Users/ianchamberlain/.config/deluge/ipc/deluge-gtk' has an unsupported type
error (ignored): error: reached end of FramedSource
error:
       … while fetching the input 'path:/Users/ianchamberlain/.config'

       error: file '/Users/ianchamberlain/.config/deluge/ipc/deluge-gtk' has an unsupported type

By comparison, nix flake and similar commands work without requiring explicit args, and I think it would make sense for home-manager to follow suit.

Maybe there is a different directory structure I could use to make this work without having to specify the flake every time?