fun fact: unflake tests pass (on my laptop) in ~18 seconds when using #CppNix / upstream #Nix, but in just ~15 seconds when using #Lix

this unscientific benchmark shows a ~17% reduction in runtime, which is pretty cool

Oh wow and C++ #nix (now?) apparently doesn't mind  #gitAnnex anymore. #lix for example refuses to do anything if the flake.lock is behind a smudge filter and your worktree is clean. You have to *manually* dirtyfy the worktree to be able to work with lix. Multiple good arguments to stay on #cppnix for me.

Had to switch back to base C++ #nix from #lix to package  #hledger's prebuilt release version, because lix still has an annoying builitins.fetchTarball bug¹ that prevents using tarballs that just contain a bunch of files without an extra single directory at the top level. (As you know, tarballs only EVER contain a top-level directory and never just a bunch of files, right?). In #cppnix it's already fixed.

¹https://git.lix.systems/lix-project/lix/issues/582
²https://github.com/NixOS/nix/pull/11195
³https://gitlab.com/nobodyinperson/nixconfig/-/commit/7198ae401c6b6dd875c7409bd009e6e59b9d8e0a#90cc0c517a4752361c635864aed25f106afccd7d_5_4

Directories referenced as `file://` URLs not fetched successfully, with a surprising error message

## Describe the bug / Steps To Reproduce ``` $ nix flake metadata file:///home/linus/scratch error: … while fetching the input 'file:///home/linus/scratch' error: tarball 'file:///home/linus/scratch' contains an unexpected number of top-level files ``` This happens regard...

Lix Systems
context:global meow repo… - Sourcegraph

Search across 2 million+ open source repositories for free. Powered by Sourcegraph Code Search.

@leftpaddotpy I'm a little (pleasantly) surprised to discover that both #Lix and #CppNix are licensed with #LGPL. I guess I got the idea that it was #MITlicence since that's what #NixOS uses.

https://git.lix.systems/lix-project/lix#license
https://github.com/NixOS/nix/?tab=readme-ov-file#license

lix

A modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth — and committed to doing right by its community

Lix Systems

@skyr Da bist du in der heiligen Dreieinigkeit¹ des Nixiversums (https://hachyderm.io/@leftpaddotpy/111071134745246898) falsch² abgebogen:

#NixPkgs ist nicht #NixOS.
#NixOS ist nicht die #NixDSL a.k.a. #NixLang.
Die #NixDSL ist nicht #NixPkgs.
(Und jeweils auch nicht umgekehrt)
Aber alle drei¹ sind #Nix.


¹Den #NixPaketmanager/#NixInterpreter (#CppNix) gibts auch noch. «Viereinigkeit»? Mannigfaltigkeit?
²Wie so manche «falsche» Abzweigung kann auch das (über Umwege) zum Ziel führen. Und man lernt die Gegend besser kennen!

[email protected] (@[email protected])

Attached: 1 image #nixlang is not #nixpkgs is not #nixos, but they are all #nix. this is immediately obvious to the most casual observer.

Hachyderm.io

I'm still working on #Nix parsing. It's a nastier language than I realized; there are a couple strange constructions I've never seen before. Here's my favorite parser quirk of the day; in #CppNix, try:

> let x = 1; in let { inherit x; }

What do you think will happen? Why?

I finally think I've figured out a basic #Nix heap using the #Haskell/#GHC technique of flagging every heap object to detect infinite loops. Cache invalidation really is hard... Fortunately, Nix is pure, so I don't have to invalidate any heap objects directly. #RPython makes it easy to hack, although it's still a bit of a slog to debug segfaults.

I think I might have to actually look at #CppNix now, or at least reread Eelco's thesis. I need to understand the differences between evaluation and instantiation.

@jakehamilton #nixpkgs is also the part with need forking the least as Eelco didn't contribute much to it anyways. The problems were all in #cppnix so the community should focus on forking it