Yann Büchau 

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
May 3, 2025 at 1:54pmWeb
Show threadYann Büchau May 5, 2025
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.
Show threadMark CrockerMay 3, 2025

@nobodyinperson Glad to read that you at least have a work-around.

Though I'm a little surprised that the top level directory convention is not being followed in a project that seems to have it's roots in UNIX. In the Windows world, it was common to package the contents of a directory in a .zip file, which caused all sorts out problems. Unpack a zip in the wrong place and cleaning up could be a real chore! I wonder if this is an artifact of #Haskell build conventions?

Show threadYann Büchau May 3, 2025

> Unpack a zip in the wrong place and cleaning up could be a real chore!

That's a user error, that's what `tar -C` et al. are for. Putting requirements on how upstream tarballs should look like for a packaging system is just silly.

@mcrocker

Show threadMark CrockerMay 3, 2025

@nobodyinperson Yes, it's a user error, but in one case, recovery is trivial.

It's also just a convention, but it's interesting that the two different communities came up with two different conventions.

Show threadLennart J. Kurzweg 🇪🇺May 3, 2025
@nobodyinperson What are the advantages of lix anyway? Is it like faster or something?
Show threadYann Büchau May 22, 2025

@noggynoggy I just re-discovered a feature of #lix that initially convinced me to use it in the first place:

A `nix develop` in a gigantic repository for some reason caused cppnix to copy the entire thing to the store (I aborted...), but somehow `lix develop` didn't. Maybe the new lazy trees thing¹ will solve this. Luckily, one can easily switch between lix and nix here.

¹https://github.com/NixOS/nix/pull/13225

Lazy trees v2 by edolstra · Pull Request #13225 · NixOS/nix

Motivation This adds a setting lazy-trees that causes flake inputs to be "mounted" as virtual filesystems on top of /nix/store as random "virtual" store paths. Only when the sto...

GitHub