| 9 Dec 2024 |
 leo60228 | the latter syntax would allow referencing PRs (via pull/123456/head) | 22:14:31 |
| 10 Dec 2024 |
|  llakala joined the room. | 00:52:34 |
 tonton | Hi, I'm on nixos and would like to switch to lixos :) I see lix is in the packages, and running 'nix-shell -p lix' and then 'nix --version' in the shell gives me 'nix (Lix, like Nix) 2.91.1'
So, is there then an easier way to switch my system to lix than the littlebit roundabout way of adding a package through my config and so on as the lix pages says? | 17:58:47 |
 K900 | There is no LixOS | 17:59:33 |
| K900 | (yet?) | 17:59:36 |
| K900 | nix.package = pkgs.lix should make your NixOS system use Lix | 17:59:47 |
 KFears (annoying) | In reply to @leo60228:matrix.org
is it expected behavior or an oversight that registry:nixpkgs/branch is supported but not registry:nixpkgs?ref=branch? It is very hard to say, as flake input URLs are in general pretty bad and inconsistent | 20:49:05 |
| KFears (annoying) | It's probably an oversight as a result of a larger design issue | 20:49:19 |
|  HeartBlin 🇷🇴 joined the room. | 23:36:49 |
| 11 Dec 2024 |
 Trans Concrete Private Ltd. (jasmine/dvnt) | What is lazy trees | 05:28:35 |
| Trans Concrete Private Ltd. (jasmine/dvnt) | And if it's anything good in concept why hasn't it been merged | 05:28:53 |
| Trans Concrete Private Ltd. (jasmine/dvnt) | If it conceptually sucks then why are they doing that | 05:30:42 |
 adisbladis | You know how Flakes copy your repo to the store on eval?
Lazy trees is a hack to alleviate some of the bad side effects of that. | 05:41:26 |
 olivia | worth noting that there are options besides "good concept that should be merged now" and "bad concept that shouldn't be attempted", including "good concept with a bad/incomplete implementation" | 05:52:07 |
| olivia | (I don't actually know enough to make any claims about what box this fits into) | 05:52:24 |
 Emma [it/its] | In reply to @adis:blad.is
You know how Flakes copy your repo to the store on eval?
Lazy trees is a hack to alleviate some of the bad side effects of that. am i the only one who prefers this behavior? | 06:48:50 |
| Emma [it/its] | (flakes getting copied to the store i mean) | 06:49:57 |
| K900 | Lazy trees still kinda does that | 06:50:28 |
| K900 | It just copies less things by default | 06:50:35 |
| KFears (annoying) | Lazy trees is like a major update in games. It's a whole bunch of refactors, features and bugfixes bundled as one big thing. It makes it so that local flakes aren't copied to store unless required by NixLang code, it makes patching sources in-memory rather than on-filesystem (which makes it so sources don't get duplicated needlessly), and it also introduces a zip VFS so that Github repos aren't unpacked | 07:12:04 |
| Emma [it/its] | unironic question: why wouldnt you want to unpack github repos? | 07:13:04 |
| KFears (annoying) | I mean, mostly that's just features that should've been there from the start, barring zip VFS which is just a very practical choice dictated by Nixpkgs being gigantic | 07:13:07 |
| KFears (annoying) | In reply to @emma:rory.gay
unironic question: why wouldnt you want to unpack github repos? So okay, to answer that, we should establish a few things first:
- Git is a poor distribution format when you don't care about the VCS features; it's slow, and it doesn't offer compression IIRC even when you do a sparse checkout
- For that reason, Github offers code downloads in
tar.gz format, which just don't have any of the VCS metadata and only have the source code. This has compression, so it's easier on the wire
tar.gz has to be unpacked to be used, because its format is somewhat ad-hoc and is quite unpredictable. Unpacking requires some CPU cycles and disk space: you do decompression and write decompressed files to disk- In concrete terms, Nixpkgs is around 40MiB compressed, and around 250MiB uncompressed (somewhat old info and check yourself but you get the point)
| 07:20:20 |
| KFears (annoying) | You would think that point number 3 is unavoidable, but it's not; zip as an archival format that has a stable layout, which allows it to be accessed as VFS. That means you can even mount it as a filesystem! Windows does this in its file manager to allow you to peek into archives, and Linux can mount zip archive as FUSE | 07:22:24 |
| KFears (annoying) | * You would think that point number 3 is unavoidable, but it's not; zip as an archive format that has a stable layout, which allows it to be accessed as VFS. That means you can even mount it as a filesystem! Windows does this in its file manager to allow you to peek into archives, and Linux can mount zip archive as FUSE | 07:22:32 |
| KFears (annoying) | Github provides not only tar.gz sources, but also zip sources, so a cute optimization you can do is to download zip archives and NOT unpack them, instead using VFS to access files from the zip archive | 07:23:30 |
| KFears (annoying) | I don't know the performance characteristics of that, supposedly random file access on zip VFS would be slower than doing that on unpacked tree, but the cool thing it does is that it saves you the decompression, so you save a bunch of disk space | 07:24:13 |
| KFears (annoying) | You could think of it as neat and very practical optimization opportunity for Nix usecases, basically | 07:26:17 |
| KFears (annoying) | The reasons why it's not merged upstream are mostly up to speculation, but some of the reasons given by CppNix maintainers were that the patchset is large, has to review, pretty big and scope, and already introduced regressions for users testing it, so they have a hard time dealing with it as it is | 07:29:04 |
| KFears (annoying) | Maybe some of those reasons are mistaken; I've been following the PR for a while and I think all of those are reasons given by CppNix maintainers like Robert to not, like, immediately merge the PR | 07:30:19 |
