Follow `~/.nix-defexpr/channels` for managing channels?
For me (Nix 2.18.2 / Mac) ~/.nix-defexpr/channels points to ~/.local/state/nix/profiles/channels. Is there any reason the pin command needs to be hardcoded to /nix/var/nix/profiles/per-user/$USER/channels?
I presume this would solve the missing /nix/var/nix/profiles/per-user/$USER issue. I don't think Nix creates this by itself anymore (maybe NixOS does though).
Actually, do we even need an explicit --profile at all? Can't we just let Nix do its thing?
https://git.lix.systems/lix-project/lix/issues/215
but yes we probably could let Nix do the thing. I'm just not 100% certain on the default semantics.
My understanding is:
- Nix prefers XDG dirs (not sure since what version, but definitely in 2.18)
- Nix respects the symlinks
~/.nix-defexpr/channelsand~/.nix-profileand will manage profiles wherever they point to - NixOS/nix-darwin/home-manager generate
~/.nix-defexpr/channelsand~/.nix-profileto point to/nix/var/nix/profilesinstead (the old location)
Actually it's more complicated than that. There's also a use-xdg-base-directories option.
https://nix.dev/manual/nix/2.22/command-ref/conf-file#conf-use-xdg-base-directories
Either way though, I think hardcoding it to /nix/var/nix/profiles/per-user/$USER/channels is wrong if nix is not configured to actually use it. The logic around it is so complex that I would rather just leave the CLI figure it out.
The thing about the pin command that mildly complicates this is it's actually primarily intended to be used as root.
But regardless, it's my view that the xdg profiles are busted by design and shouldn't be used. I do know about the permissions setting issue on macOS, and I think we fixed it in Lix?
The thing about the pin command that mildly complicates this is it's actually primarily intended to be used as root.
Hm, don't we already have conditional logic for root when managing profiles though?
But regardless, it's my view that the xdg profiles are busted by design and shouldn't be used. I do know about the permissions setting issue on macOS, and I think we fixed it in Lix?
Completely agree that this is busted for a number of reasons, but Lix is not currently an option where I'd like to adopt this. So it's just a fact of how Nix works right now.
I mean it's not a big deal really, just wanted to understand if there's a reason it's hardcoded. This is a really small wrapper around nix-env so I might just re-implement it the way I need it to work downstream. Love this btw!
Hm, don't we already have conditional logic for root when managing profiles though?
In flakey-profile? Yes. We could probably change it to also be more careful with which profile it is poking for channels. But my worry is that people could easily get confused by having multiple <nixpkgs> from channels, which is a really good way to gaslight yourself with the computer, and I would somewhat like to avoid encouraging it. Also, hm, I think that for channels we can't actually make Nix figure it out for us, since it's not actually the default profile (which has software installed in it), but a second other profile named something different.
Lix is not currently an option where I'd like to adopt this
Just curious, any particular reason? I mean the fact that we just have HEAD and haven't tagged a proper release yet is a rather excellent reason! We're actively working on that bit as a team and it will be released when our processes to release it, and remaining bugs, are done.
Also, hm, I think that for channels we can't actually make Nix figure it out for us, since it's not actually the default profile (which has software installed in it), but a second other profile named something different.
I see yeah, I might need to better test this myself.
Just curious, any particular reason? I mean the fact that we just have HEAD and haven't tagged a proper release yet is a rather excellent reason!
Precisely the reason. Company policy. Besides that I'd also like to wait a few releases to see how this plays out before advocating for something that's going be running on other people's machines (not just mine).
Makes perfect sense in regard to the release :) we have to draw the rest of the metaphorical owl but it's coming quite soon.
Besides that I'd also like to wait a few releases to see how this plays out before advocating for something that's going be running on other people's machines (not just mine).
I greatly sympathise. There's a bunch of context that makes me think that the status quo of not switching to Lix isn't a neutral choice, because things are about to get actively worse from under you in the status quo.
For example, CppNix has been pinned at 2.18 for nearly a year due to a substantial unfixed regression pile in later versions related to libgit2 and lazy trees, both of which inherently don't affect Lix by virtue of not being in it. This pin is currently being let go because the CppNix maintainers in nixpkgs all resigned since they all work on and use Lix exclusively, switching back to the CppNix team itself maintaining it in nixpkgs again (which, they stopped because every third release for the past three years had been reverted for regressions and the now resigning maintainers took over to stop that pattern), so the protection against these regressions hitting infra will soon be gone.
The new state is actually even less protected than the 2.13 etc revert messes in the past, since the people who were fighting to revert breakage in the past (even non maintainers) switched to Lix and are no longer affected by the stability of CppNix, so have no reason to fight for its stability anymore.
I offer this as context rather than as persuasion; it's not a significant goal of mine to get individual people to use Lix. Feel free to make your own decisions :)
Yep, I'm well aware of the libgit2 mess, and it affects us as well. That's why we're still on 2.18, and given how things are going we'll probably be on 2.18 for quite a while, at least until we see how this plays out. I'm definitely keeping Lix in mind and actively tracking its progress.