Nix Office hours

I want to thank Tom for letting me have this awesome OfficeHours experience.
Coming from ops background and having little knowledge of languages, especially functional programming, I’ve been struggling to get past this learning curve of nix.
Still am, however I am very happy that in this short hour we managed to go through:

  • Talk about flakes. The problems it’s trying to solve. Benefits of using it.
  • Helped me better understand lib.mkOption. How to use it when creating variables. (And I thought I knew what I was doing.:sweat_smile:)
  • Talked about IaaS and tools(NixOps deploy-rs morph krops) available to manage it.
  • Learned about a builtins.trace I wish I knew at the time I picked up learning nix.
  • Learned about existing matrix community channel.
  • Presented some fancy stats about nix having 60+ packages and surpassing AUR. Lost the link.

Honestly as I saw Tom explaining I wanted to stop him at every other sentence and try to expand on things. I’ve got enough homework to work on.

Thank you so much for your time and this initiative! I did miss 2 hours of my OfficeHours that I had to catch up on, therefore I was unable to checkout General Nix Office Hours on jitsy but I hope there will be more of those in the future!

3 Likes

@simisimis I think this is probably the link you lost: Graphs - Repology

yes! thx, was googling for distrology :sweat_smile:

Had a great session.
I specifically had a question about a situation I got myself into where I had about 60GB of duplicate packages. I found out where most of those duplications came from before the call (I used the -p option on nixos-rebuild wrong), but some packages were still duplicated multiple times (apparently).

Tom told me about the following tools to explore where these duplications came from:

  • nix-store --delete /nix/store/foo gives reasons why a package cannot be deleted.
  • nix-store --query --referrers /nix/store/foo shows which packages refer to the given package.
  • nix why-depends /run/current-system /nix/store/foo recursively lists packages requiring the specified package, basically a more powerful version of nix-store --query --referrers.
  • nix-store --gc --print-roots | grep -v proc prints gcroots which are not a result of running processes.

After doing this for several seemingly duplicate packages we found that they were not actually duplicate but instead came from packages requiring different versions of the same library.

Tom also recommended me the great nix-du tool which uses graphviz to visualize dependency graphs of nixos installations based on size.

5 Likes

Thank you for the session, @tomberek . Learned about:

And more.