!9IQChSjwSHXPPWTa:lix.systems

Lix

1103 Members
Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms294 Servers

Load older messages


SenderMessageTime
15 May 2024
@qyriad:katesiria.orgQyriad
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@qbit:tapenet.orgI figured there was a reason why it wasn't there already16:39:55
@qyriad:katesiria.orgQyriadSo 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 carefully16:40:52
@qyriad:katesiria.orgQyriadConvenience is at odds with purity 😔, 'tis the balance we walk16:41:45
@qyriad:katesiria.orgQyriad 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@qbit:tapenet.org fortunately shell scripts \o/ 16:52:19
@qbit:tapenet.org@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:katesiria.orgQyriadYeaaaaah everyone really has a bunch of Nix wrapper scripts huh (including us)16:52:55
@qyriad:katesiria.orgQyriad 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@qbit:tapenet.orginteresting16:54:50
@qyriad:katesiria.orgQyriad That lets you write things like xil build -CE '{ pkgs }: pkgs.hello' (-E for --expr) 16:55:23
@qyriad:katesiria.orgQyriad 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
@sersorrel:matrix.orgsorrel joined the room.16:58:59
@qbit:tapenet.org@qbit:tapenet.orgnice, I have found myself wanting to do exactly that sometimes :D17:06:14
@mangoiv.:matrix.orgMangoIV
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.:matrix.orgMangoIV 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.:matrix.orgMangoIV 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:katesiria.orgQyriad
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.:matrix.orgMangoIV 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:katesiria.orgQyriad
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:katesiria.orgQyriad 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:katesiria.orgQyriad
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:katesiria.orgQyriad 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.:matrix.orgMangoIV Yeah that’s fair . 17:18:46
@mangoiv.:matrix.orgMangoIV(Imagine a —reproduce flag btw)17:19:14
@mangoiv.:matrix.orgMangoIV Probably almost impossible to implement in the general case thojfh 17:19:56
@qyriad:katesiria.orgQyriad Probably 😔 17:20:13
@mangoiv.:matrix.orgMangoIV* Probably almost impossible to implement in the general case thougj17:20:13
@mangoiv.:matrix.orgMangoIV* Probably almost impossible to implement in the general case though17:20:22
@qyriad:katesiria.orgQyriad May the eventual lix CLI (third time's the charm…) solve all our problems =P  17:24:05

There are no newer messages yet.


Back to Room ListRoom Version: 10