Newest at the top
2025-09-23 12:05:46 +0200 | <dminuoso> | Here I have 22 nixpkgs instantiations in my store for just 4 NixOS deployments. :-) |
2025-09-23 12:03:32 +0200 | <jackdk> | Ideally the flake providing the package should provide an overlay to splice it into your config how you wish, but that's very rare. Agree that the inputs.foo.nixpkgs.follows is the "standard" but sadly less common than it should be |
2025-09-23 12:03:01 +0200 | <dminuoso> | So you get tractability, reproducability and ability to specify what it is you need exactly. |
2025-09-23 12:02:46 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
2025-09-23 12:02:46 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:7054:843b:4b80:a9d) (Changing host) |
2025-09-23 12:02:46 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:7054:843b:4b80:a9d) |
2025-09-23 12:02:46 +0200 | <dminuoso> | But overridable. |
2025-09-23 12:02:42 +0200 | <dminuoso> | Its lockable |
2025-09-23 12:02:40 +0200 | <dminuoso> | The way cabal packages do it is fairly good already. You talk about flags and versions (i.e. constraints) |
2025-09-23 12:02:01 +0200 | <haskellbridge> | <Morj> Did nodejs devs write this |
2025-09-23 12:01:54 +0200 | <haskellbridge> | <Morj> Wtf |
2025-09-23 12:01:42 +0200 | <haskellbridge> | <Morj> Sometimes the hardwired references are good actually. But I should say they should be guarded with «syntactic salt» and not advertized in the tutorial |
2025-09-23 12:01:37 +0200 | <dminuoso> | Morj: Heh, funny story about that: Nix updates that lock file for you without even asking for confirmation in a few different circumstances. |
2025-09-23 12:00:57 +0200 | <haskellbridge> | <Morj> Unfortunate. Seems like you can copy a flake description and patch it at least |
2025-09-23 12:00:55 +0200 | <dminuoso> | The flaw here is that packages are solved based on hardwired references, not on resolvable labels. |
2025-09-23 12:00:16 +0200 | <dminuoso> | People generally dont. |
2025-09-23 12:00:08 +0200 | <dminuoso> | So you write `inputs.foo.nixpkgs.follows = "nixpkgs";` in your flake |
2025-09-23 11:59:43 +0200 | <dminuoso> | So its a contract that everyone should obey. |
2025-09-23 11:59:43 +0200 | <haskellbridge> | <Morj> On the other hand, flakes CLI has some other crazy things like that interaction with git |
2025-09-23 11:59:36 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-23 11:59:33 +0200 | <dminuoso> | Morj: There is, you have to do it manually for each input. |
2025-09-23 11:59:21 +0200 | <haskellbridge> | <Morj> That's the part I also don't understood about flakes. I suppose there should be a way to deduplicate or override deps? Would be crazy if there isn't |
2025-09-23 11:58:43 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 250 seconds) |
2025-09-23 11:58:29 +0200 | <dminuoso> | Outside of nixpkgs at least. |
2025-09-23 11:58:23 +0200 | <dminuoso> | Which is why a single package can easily drag 5-6 different nixpkgs instanations with it. |
2025-09-23 11:58:07 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
2025-09-23 11:58:04 +0200 | <dminuoso> | Who knwos. |
2025-09-23 11:58:02 +0200 | <dminuoso> | What about fancy-programs dependencies? |
2025-09-23 11:57:58 +0200 | <dminuoso> | You have to make sure that fancy-program uses your nixpkgs, and not its own. |
2025-09-23 11:57:48 +0200 | <dminuoso> | So if you want to include "fancy-program" into your nix-darwin installation.. |
2025-09-23 11:57:36 +0200 | <dminuoso> | They expose fully ready derivations based on pinned nixpkgs. |
2025-09-23 11:57:27 +0200 | <dminuoso> | magic_rb: No thats still wrong. Here's why: flakes generally dont expose callPackage pattern! |
2025-09-23 11:57:15 +0200 | <haskellbridge> | <magic_rb> They dont, thats a fundamental nix thing, everything is content addressed/input addressed. If you patch glibc you have to rebuild, thats just a fact |
2025-09-23 11:56:49 +0200 | <haskellbridge> | <Morj> But I want to say that a giant blob is not a bad thing |
2025-09-23 11:56:44 +0200 | mange | (~mange@user/mange) (Quit: Zzz...) |
2025-09-23 11:56:38 +0200 | <haskellbridge> | <Morj> Outside flakes you get a giant blob where everything relies on everything. So if you do a security update you need to rebuild the world. I'm not too familiar with how flakes change this |
2025-09-23 11:56:35 +0200 | <haskellbridge> | <magic_rb> dminuoso no, again, wrong. If you use nix-darwin it doesnt matter what its nixpkgs input is. Since nix-darwin, like home-manager or nixng exposes a function which takes a instance of pkgs and builds your system from that |
2025-09-23 11:56:00 +0200 | <dminuoso> | With flakes its also fairly impossible |
2025-09-23 11:55:54 +0200 | <dminuoso> | Outside flakes its completely impossible since there's just hardwired buittins.fetchXXX things. |
2025-09-23 11:55:40 +0200 | <dminuoso> | Morj: Yes, both. |
2025-09-23 11:55:36 +0200 | <haskellbridge> | <Morj> *not feasible to force-update |
2025-09-23 11:55:35 +0200 | <dminuoso> | But the second you want any other package you like, you have to wire things together, and just pray that the entire transitive dependency closure does so as well. |
2025-09-23 11:55:23 +0200 | <haskellbridge> | <Morj> Are we talking about flakes or the nix way in general, that makes security updates unforsable? |
2025-09-23 11:55:13 +0200 | <dminuoso> | magic_rb: Thats not up to you. If the *only* flake you ever use is github:nixpkgs, then fine. |
2025-09-23 11:55:01 +0200 | <haskellbridge> | <magic_rb> So again, the mechanisms are in place and people are holding it wrong much of the time |
2025-09-23 11:54:40 +0200 | <dminuoso> | Though that reproducibility is silly since all you need is just a lock file. |
2025-09-23 11:54:35 +0200 | <haskellbridge> | <magic_rb> If nix-darwin is using nixpkgs for anything but lib its doing it wrong |
2025-09-23 11:54:22 +0200 | <dminuoso> | The nix way is rigid and reproducible, but not tractable. |
2025-09-23 11:54:12 +0200 | <dminuoso> | Because it gets tractable. |
2025-09-23 11:54:07 +0200 | <dminuoso> | magic_rb: It means you cant force security updates. Having a constraint/dependency resolver is just far superior. |