Threads for Charly

  1. 2

    Bought the book, looking forward to high quality sources for learning Nix

    Especially would like to understand how to debug Nix flakes and expressions

    1. 1

      For my personal tooling I use flakes for individual repositories b/c the built-in template and integrations (like poetry2nix for python applications) is a direct upgrade to what we had before.

      For my nixos configurations though I dislike using flakes. My main gripe with flakes is that it effectively becomes the entrypoint or ‘main’ of the configuration, which it makes it annoying to use with other tools like morph and the outputs section forces a certain structure to the code where I would prefer it work like niv where it sets up dependencies but the end result is just imports to your regular code.

      1. 1

        @cadey has your position on flakes changed? My earlier interpretation from earlier writing is that you favored tools like niv and morph which eschew the flake model completely. I also see that still recommends niv ( so wondering what the community thinks about flakes in general

        1. 5

          My position on flakes is that they are slightly less terrible than using NixOS normally. They ain’t perfect but they could be so much worse than they are. I’m happy with the usability as-is. Also see here for more words about the kind of mindset change that I had once I hit the satori moment with flakes.

          1. 2

            wondering what the community thinks about flakes in general

            No idea about “the community” (I really hate those terms), but I found flakes easier to get into than anything that came before that always felt “tacked on like spaghetti stapled together”.

            I’m doing more with nix now that I ever have now that flakes are “officially” here. Yes experimental but i now have a repo for my entire home config, I have that setup so I can build auto installing iso images, have secrets setup too, and build a system with my home config all in one deploy step via deploy-rs.

            In my view flakes are already useful enough to make me not care about what came before which I avoided to be honest. Perfect no but good enough for government work as they say.

        1. 1

          Somehow that blog managed to break keyboard scrolling!

          1. 1

            Hmm, I’ll look into it. I used an off the shelf Hugo theme, most is the JS is around syntax highlighting.

          1. 7

            Probably one of the best use cases for functional package managers right now is for creating reproducible development environments on any machine. I am looking to set up Nix on both my Mac and Linux servers so my toolchain remains consistent between environments.

            1. 7

              I looked into it last night and it has a serious issue on Catalina. One hopes they resolve it soon.

              1. 4

                There are relatively straightforward fixes to create a synthetic drive at /nix. It’s not official yet, but it works just fine.


                1. 3

                  This is what I use and what I’m going to include in my tutorial post that I’ll be writing in the next week.

            1. 0

              The shortcomings of monorepo is not about the concept but about using git for that.

              1. 1

                Git virtual file system should make git viable, especially as GitHub implements it. I think git has mechanisms for partial repo checkout, unsure.

                1. 1

                  Git VFS gets your repo size from a handful of GB to a few hundred GB. Nobody knows if it scales further.

                  I wonder how such big repositories deal with other aspects like a huge number of branches and tags. Also, the lack of fine grained access control is not solved afaik. Did they consider a switch to Subversion?

                  1. 1

                    Im not sure who you are talking about here, Google has there own custom source control system [1] and Facebook is investing in improving mercurial currently. Google created the concept of the CODEOWNERS file for access control which GitHub ended up implementing. Microsoft is committed to scaling Git through VFS because of the GitHub acquisition.


              1. 2

                The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos. One place I see multirepos fall over is awful dependency management practices internally and in open source. Many dependencies quickly become outdated and are not updated in cadence, slowing down writers and consumers. Better tooling can help here but an organization needs real discipline to stay on top of things.