| 7 Oct 2024 |
 waltmck | Is there any way to follow the latest released Lix module from a flake? The guide suggests hardcoding the latest release (currently https://git.lix.systems/lix-project/nixos-module/archive/2.91.0.tar.gz) and I am currently following https://git.lix.systems/lix-project/nixos-module/archive/main.tar.gz, but this leads to a rebuild pretty much every time I update my flake.lock | 22:40:29 |
 @jade_:matrix.org | nope, there is a bug filed in lix releng for this, and it has not been done because it would simply need doing.
i don't think the guide should be saying that though; the module version should match the lix version | 22:41:40 |
| @jade_:matrix.org | the module should be 2.91.0 and you just don't have to specify the lix version at all. curious where you're seeing the wrong info as we should fix this | 22:42:12 |
| @jade_:matrix.org | * the module should be 2.91.0 and you just don't have to specify the lix URL at all. curious where you're seeing the wrong info as we should fix this | 22:42:21 |
| waltmck | https://lix.systems/add-to-config/ | 22:42:52 |
| @jade_:matrix.org | yeah, so that gives you two options: the flake (which contains the URL to lix within it) and the non flake, which gives you both URLs at a specific version with a hash so they don't refetch themselves | 22:44:02 |
| @jade_:matrix.org | but if you are asking about rebuilds, that is an unrelated thing: that's because lix does not have a binary cache with more than "the exact version we released" | 22:44:36 |
| @jade_:matrix.org | * but if you are asking about rebuilds, that is an unrelated thing: that's because lix does not have a binary cache with more than "the exact version we released built with the exact version of nixpkgs we built it with" | 22:44:45 |
| waltmck | I'm only asking about rebuilds because I only want to rebuild when a new version is released | 22:44:55 |
| @jade_:matrix.org | if you want to use lix from nixpkgs, the module has a lixFromNixpkgs attribute (which is importing the overlay with lix = null;) | 22:45:18 |
| waltmck | I don't want to rebuild for some minor changes to main.tar.gz unless there is a new version. I was hoping that there was some latest-version.tar.gz which I could follow instead | 22:45:24 |
| @jade_:matrix.org | that's not why you are rebuilding though | 22:45:34 |
| @jade_:matrix.org | you are rebuilding because nixpkgs changed | 22:45:38 |
| waltmck | ah I see | 22:45:53 |
| @jade_:matrix.org | using the lix shipped in nixpkgs fixes this. and our overlay can still be used with lix from nixpkgs as well | 22:46:03 |
| waltmck | How does that work? I include the module and also put nix.package = pkgs.lix;? | 22:46:47 |
| @jade_:matrix.org | https://git.lix.systems/lix-project/nixos-module#flake-structure-and-usage there is some documentation of that option here. i was waiting for 2.91 to get into nixpkgs before updating the main user facing page (which happened like a month ago. so much to do.) | 22:47:07 |
| @jade_:matrix.org | In reply to @waltmck:matrix.org
How does that work? I include the module and also put nix.package = pkgs.lix;? so the module installs an overlay that turns pkgs.nix into pkgs.lix. if you give it lix sources rather than null, it will also build lix and put it as pkgs.lix. | 22:47:54 |
| @jade_:matrix.org | nix.package need not be set, since pkgs.nix is now lix | 22:48:10 |
| @jade_:matrix.org | https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix#L54 see this code in the overlay | 22:48:52 |
| @jade_:matrix.org | anyway i am going away from my computer, gl | 22:49:06 |
| waltmck | Thanks! | 22:49:40 |
| @jade_:matrix.org | also note the tradeoffs listed on https://lix.systems/add-to-config/ at the top for why it's like this. the secret third option of lix nixos module with lix from nixpkgs as i just mentioned now is not listed there, but it gets you the benefits of the module without rebuilding lix constantly | 22:50:43 |
| waltmck | I get the warning
warning: This Lix NixOS module is being built against a Lix with a
major version (got 2.91.0) other than the one the
module was designed for (expecting 2.92). Some downstream
packages like nix-eval-jobs may be broken by this. Consider using a
matching version of the Lix NixOS module to the version of Lix you are
using.
I think this is because I am using HEAD rather than the last stable version of the overlay (as mentioned here)
| 22:52:49 |
| waltmck | To be clear, there is no overlay which follows the nixpkgs version of Lix and I will need to hardcode until the bug filed in lix relang is done? | 22:54:08 |
| waltmck | Rereading the transcript I think so, thanks again for your help | 22:59:07 |
| 8 Oct 2024 |
| @jade_:matrix.org | In reply to @waltmck:matrix.org
To be clear, there is no overlay which follows the nixpkgs version of Lix and I will need to hardcode until the bug filed in lix relang is done? not only that, there cannot really exist one without it being a giant pain in the neck. maintaining date based dependencies is a pain in the neck, and it is unclear how one would even "properly" schedule one in step with nixpkgs and in step with our own release schedule since nixpkgs takes a while to get new versions of lix.
the correct way for this to be handled is if something like our overlay is upstreamed into nixpkgs itself.
| 01:34:16 |
 uep | FWIW, this is mildly annoying too.. (but not worth the effort)
❯ nix why-depends /run/current-system /nix/store/1fp0ggfyfgn6ydsgc8sdwqv5n5gn9nal-nix-2.18.8
/nix/store/2c2dc6204dw2pqj3hrgdwdsfravvk604-nixos-system-oenone-24.11.20241004.bc947f5
└───/nix/store/iwmxfmj8iyla2lvz3a6afn898j5dgmx7-system-path
└───/nix/store/llbdd2sm6n01m8lf6y1ix5kfzfp0d2hv-nixos-option
└───/nix/store/1fp0ggfyfgn6ydsgc8sdwqv5n5gn9nal-nix-2.18.8
| 01:57:57 |
| uep | I don't really know why the nix attribute it pulls in isn't the one overlayed to lix, but.. whatever | 01:59:05 |
| @jade_:matrix.org | In reply to @uep:matrix.org
I don't really know why the nix attribute it pulls in isn't the one overlayed to lix, but.. whatever it's because of something more depressing | 02:06:18 |
