no-absolute-path-literals experimental feature

[roberth]

Is your feature request related to a problem? Please describe.

Path values are unfit for use as a "path string" replacement because for example

''
  HomeDirs: ${/home}
''

tries to add /home to the store.

In my experience, the only appropriate use is for referencing source files and locations within a repository. These path values are all created with relative path literals.

Describe the solution you'd like

Add an experimental feature flag or setting that disables absolute path literals such as /. and /home or /var/lib/foo.

Describe alternatives you've considered

• Status quo. Keep telling users not to write absolute path literals
• Deprecate them even more. Users would have to opt out of this flag to use /..

Additional context

Priorities

Add 👍 to issues you find important.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-07-31-nix-team-meeting-minutes-76/31486/1

[Ericson2314]

Strong agree. I've been bit by sketchy code breaking when realStoreDir != storeDir which is the same problem. Better to just be able to catch and prohibit that code outright.

[Ericson2314]

This has the nice side-effect of lessoning the gap between impure and pure eval too.

[thufschmitt]

Discussed during the Nix maintainers meeting on 2024-01-22. Confirmed to be approved

Don't know yet how to deprecate things (needs something like the Nix language version RFC). But we can still do a warning on style / lint rather than deprecation grounds.

• @pennae: As long as the warning can be disabled.
• @roberth: Needs to very well-documented. Warning should link to manual.
• @Ericson2314: This would be our first such toggle language warning. Exciting!
• @Ericson2314: If the abs path begins with the store dir, the warning should mention builtins.storeDir.
  • I've done IFD with chroot store, and seeing things stop working because absolute paths to a store paths (which results in re-coppying, yuck!) was used.
• @roberth: Paths are trickier than beginners expect, so catching an almost-always bad usage is helpful

Idea approved. (Actually, already was!)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-01-22-nix-team-meeting-minutes-117/38838/1

[7c6f434c]

Absolute paths are useful for properly separating repositories in some cases (static configs might live completely separately from complicated generator code), but fortunately at least replaceable by symlinks.

How far is ../ allowed to go, by the way?

[roberth]

for properly separating repositories

In flakes those would come in through the lock file, and/or --override-input if you need to use local changes. Absolute paths are allowed in --override-input (as well as the lock file if you really don't want to use a forge as 'source of truth').

For the non-flakes scenario, I can see alternatives:

• symlinks (I wouldn't think of that; have a phobia for them)
• NIX_PATH, -I
  • or a similar feature that allow-lists provided paths
• a setting to opt out
• switch to relative paths
  • e.g. put your repos in the same parent directory and use ../foo
  • echo 'import ../../home/user/config/zeus/configuration.nix' >/etc/nixos/configuration.nix
    • import more clearly defined than symlink - remember the phobia

... and that brings us to

How far is ../ allowed to go, by the way?

My proposal here is about path literals, not path values necessarily, so there would be no such restriction.
There's something to be said for this kind of restriction, e.g. not being able to "escape" to storeDir from a fetchTree result using ./.., but that should be considered separately. This proposal may already be quite disruptive as is.

[7c6f434c]

flakes

Meh, I do too many Nixpkgs inputs with config via environment variables, so flakes won't pay off for me. Wasn't sure if references to non-Nix files via flake input works either, good if they do.

import

That's not enough for me — static configs include static configs in languages othen than Nix, most recent example — a colorscheme to feed to a Konsole wrapper script but also usable without any involvement of Nix.

-I

Oh right, I try to avoid use of <something> for non-Nix stuff unless 100% unavoidable like importing setuid wrapper source from NixOS, but that's a matter of taste and this workaround should be documented (I didn't think of adding a completely non-Nix repo to NIX_PATH but it's a good idea to offer the option to the users!)

a setting to opt out

Well, my first reflex was to check do I have enough arguments to push for a long-term commitment to keep this setting and not break it later. The workarounds are actually cleaner and pretty good and diverse, so not really.

your repos in the same parent directory

I kind of try to avoid it, but it's also true that there is no Nix restriction here, I don't expect the set of VCSes I consider good idea for my personal config to intersect with the set of VCSes Nix (not just Nixpkgs fetchers) supports.

Thanks for the overview of alternative options, that's indeed a useful checklist!

[roberth]

import

That's not enough for me

Understood. I only included it as it might be the singular exception needed by users who otherwise use a single repo.