| 15 May 2024 |
Qyriad | In reply to@ma27:nicht-so.sexy given nix build foo, how would this differentiate between nixpkgs#foo and foo being an installable (e.g. a directory in the cwd with a flake.nix inside)? (And yes, the syntax ambiguity too) | 16:39:24 |
@qbit:tapenet.org | I figured there was a reason why it wasn't there already | 16:39:55 |
Qyriad | So yeah, not a "No" — we care a lot about Lix's UX, and if we can make it better without adding more confusion or design issues we will later regret, we absolutely will, but we gotta think them through pretty carefully | 16:40:52 |
Qyriad | Convenience is at odds with purity 😔, 'tis the balance we walk | 16:41:45 |
Qyriad | nix-env (and nix-shell -p) actually has behavior similar to what you're describing, though with way more problematic defaults and implementation. nix-env has a notion of the "active Nix expression", which is what it uses if you do something like nix-env -iA foo — it looks up foo relative to the "active Nix expression". The active Nix expression is determined by the contents of the path ~/.nix-defexpr (or ~/.local/state/nix/defexpr with XDG mode), which iwrc was generally setup by default to point to /nix/var/nix/profiles/per-user/root/channels/nixpkgs (or something, don't remember exactly what), precisely so you can just do things like refer to a package by name without needing the "nixpkgs" boilerplate | 16:48:50 |
@qbit:tapenet.org | fortunately shell scripts \o/ | 16:52:19 |
@qbit:tapenet.org | ni() {
if [ "$#" -eq 0 ]; then
echo "please specify packages to install"
return 1
fi
opts=()
for i in $@; do
opts+="nixpkgs#$i"
done
echo "==> Installing: $opts"
nix shell $opts
}
| 16:52:26 |
Qyriad | Yeaaaaah everyone really has a bunch of Nix wrapper scripts huh (including us) | 16:52:55 |
Qyriad | Something we did for Xil — which you can think of as our "Lix experiment playground", is we gave it a --call-package/-C flag, which applies a Nix function to your argument, which can be arbitrarily set by the user, but defaults to target: let pkgs = import <nixpkgs> { }; in pkgs.callPackage target | 16:53:55 |
@qbit:tapenet.org | interesting | 16:54:50 |
Qyriad | That lets you write things like xil build -CE '{ pkgs }: pkgs.hello' (-E for --expr) | 16:55:23 |
Qyriad | Or, often more usefully: xil build -CE '{ callPackage }: callPackage ./some/package.nix { withFoo = true; }', which under Nixpkgs conventions is a pattern that comes up often but is surprisingly annoying to do in any of the Nix CLIs | 16:58:46 |
| sorrel joined the room. | 16:58:59 |
@qbit:tapenet.org | nice, I have found myself wanting to do exactly that sometimes :D | 17:06:14 |
MangoIV | In reply to @qyriad:katesiria.org Nix (including Lix) has a general problem where a big part of its entire purpose is to avoid implicit state, specifically the combination of those two. We can't avoid state, and lots of things have to happen implicitly, but we should avoid state being implicit unless there is a really really good reason. <nixpkgs> and nixpkgs in the flake registry were both considered to have sufficiently good reason: you need Nixpkgs to do literally anything. But under nix-channel, and with the online flake registry on non-NixOS, both can point to different things depending on context and from behind-the-scenes changes (on NixOS unstable, and the new release, both will point to the system's Nixpkgs thanks to Jade).
Both <> search paths and the flake registry have been rightfully criticized, but their introduction was not without reason: needing to specify a URL, even an abbrevited one like github:NixOS/nixpkgs, any time you need anything would be really fucking annoying. So there are times when implicit state is necessary for usability, but when we do, we need to be very careful when designing it so we don't fall into more traps and create more confusing caveats for users to be aware of Don’t forget that you would have to add the rev as well. | 17:09:45 |
MangoIV | I don’t think the idea of nix being stateless extends very well to the commands you use to interact with it. | 17:10:12 |
MangoIV | I think convenience and what a user would expect should go over ideal, especially when there’s already a habit of doing these things, why not go all the way | 17:11:02 |
Qyriad | In reply to @mangoiv.:matrix.org I don’t think the idea of nix being stateless extends very well to the commands you use to interact with it. I mean yeah, that's the problem =P That's why we do accept implicit for these things, because otherwise actually using Lix would be untenable for all but your most die hard purists | 17:11:50 |
MangoIV | If I tell beginners “no you have to add nixpkgs# here” (which I did at least 10 times with different people) I set myself up for explaining the registry anyway | 17:12:04 |
Qyriad | In reply to @mangoiv.:matrix.org I don’t think the idea of nix being stateless extends very well to the commands you use to interact with it. * I mean yeah, that's the problem =P That's why we do accept implicit for these things at all, because otherwise actually using Lix would be untenable for all but your most die hard purists | 17:12:05 |
Qyriad | I would argue that one specifically is a docs and error messages problem more than a convenience problem (though we intend to address both) | 17:12:43 |
Qyriad | In reply to @mangoiv.:matrix.org I think convenience and what a user would expect should go over ideal, especially when there’s already a habit of doing these things, why not go all the way I disagree with "going all the way", though. We want to address these convenience issues — we::Qyriad personally don't care that much about the exact reproducibility of the CLI commands we run on a day to day basis. But things that degrade purity for convenience should either be opt-in in some fashion, be such an obvious win that there's basically no reason to not, or be really carefully designed. | 17:15:43 |
Qyriad | Like, again to be really clear: we want the usability wins. We talk about ways we could improve this all the time. We just don't want to create more footguns in the process | 17:16:43 |
MangoIV | Yeah that’s fair . | 17:18:46 |
MangoIV | (Imagine a —reproduce flag btw) | 17:19:14 |
MangoIV | Probably almost impossible to implement in the general case thojfh | 17:19:56 |
Qyriad | Probably 😔 | 17:20:13 |
MangoIV | * Probably almost impossible to implement in the general case thougj | 17:20:13 |
MangoIV | * Probably almost impossible to implement in the general case though | 17:20:22 |
Qyriad | May the eventual lix CLI (third time's the charm…) solve all our problems =P | 17:24:05 |