Open roberth opened 1 year ago
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
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.
This has the nice side-effect of lessoning the gap between impure and pure eval too.
Discussed during the Nix maintainers meeting on 2024-01-22. Confirmed to be approved
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
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?
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:
NIX_PATH
, -I
../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.
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!
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.
Is your feature request related to a problem? Please describe.
Path values are unfit for use as a "path string" replacement because for example
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
/.
.Additional context
Priorities
Add :+1: to issues you find important.