Determinate Systems Blog

Yeah, and that's obviously pretty hostile when the best guide is reading the source. I think the deeper problem that maybe isn't always considered in the "Nix needs better docs" discourse is that there are many tasks that simply don't have an optimal workflow in Nix (yet). It can be weird documenting how do some particular thing, but having to frontload that doc with a bunch of caveats about which particular set of tradeoffs the suggested approach is embracing. For example with Python, a huge one is around how much you want to leverage the Python packages already in nixpkgs. If you want to use them, which makes sense if you don't really care about versions or you've got a lot of things with tie-ins to non-Python such as bindings packages, then you probably want the conventional buildPythonPackage workflow, where you manually package any missing deps, perhaps assisted by pip2nix: https://wiki.nixos.org/wiki/Python But if you have a self-contained app that already has everything locked and you just want minimum friction, then you almost certainly want uv2nix: https://github.com/pyproject-nix A lot of things in Nix are like this. Same story with containers where you've got dockerTools.buildImage but depending on your workflow nix2container is almost certainly the better choice. Nix's limitations around IFD are finally being addressed by https://tvix.dev/ but that's a rewrite and brings yet another potential split. Nix is the epitome of being perpetually stuck in the 1000…

Thank you, we will! =). I think there is a lot of opportunity here around a cohesive workflow around Nix. That is a big part about what I was consulting on for so many years. Maybe check out our demo on our home page: https://determinate.systems/ -- you might like it.

I believe so, it seems like almost all (or all?) solutions listed here: https://news.ycombinator.com/item?id=39696038 use flakes underneath. I think the flakes problem come from two things: - flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now - there seems to be some bad blood[1] between https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some. But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old. [1] https://discourse.nixos.org/t/introducing-flakehub/32044

Although Guix reads better than Nix (after all, it's Lisp), I found the support and resources available for learning severely lacking. Plus, you have to jump through hoops to install non-free software, which goes against the ethos of Guix anyway. IMHO, Nix is clearly "the winner" here and we'll see more and more adoption as it improves. Lots of folks are doing exciting work (see https://determinate.systems/, https://devenv.sh/, https://flakehub.com/). And the scale and organization around nixpkgs is damn impressive.

What is Determinate Systems, the official group behind Nix? Not at all clear to me from the site: https://determinate.systems/ (Also, the support(?) phone number at the bottom seems pretty unusual!) Just trying to get my head around, as a Nix-interested non-user (other than toying with it briefly years ago) what Flake is, who it's from, how important the controversy mentioned elsewhere is, if I should care, if I'm just starting whether I should use it or not, etc.

In the past three weeks I've explored two use cases: 1. Macbook setup via nix-darwin + home-manager. Now that I've put in the time, I'm going to use it for my personal and family laptops. I would probably not recommend anyone else do this if they have not previously used Nix. Very high ramp given the benefits. 2. Dev environments[1]. I started using nix+direnv for my side projects. This was quick and easy to get started with and has been great. Would recommend anyone look into it via the link below. I have not tried installing/using NixOS. [1] https://determinate.systems/posts/nix-direnv

> Did it significantly improve in the past two years? I feel like I can pretty concretely answer with “no”. The docs are hard to read and don’t cover content well, and the ecosystem split that flakes brought have made it more complicated than ever for a new user to jump in today. There’s plenty of user generated content out there. Sometimes it can fill in a gap, but most of the time I find that I have to just figure it out myself. Nix is a cool system overall but the learning curve still seems needlessly steep. https://determinate.systems seems to be doing good work for the nix community though. Shout out to them for sure.

If you're using nix to build your repo, it's worth adding scripts for releases etc and run them locally and as part of the ci https://determinate.systems/posts/nix-github-actions

The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything. The learning curve was so incredibly steep it almost felt like the people behind Nix were being malicious or intentionally gatekeeping. You finally stumble onto something you can at least partly understand, but then the powers that be throw two last obstacles at you like, First, flakes are "experimental", so you have to enable them. Back then there were like three slightly different CLI commands to do it, and it felt like none worked from like 5 tutorial tabs I had open, putting it `experimental-features =` into flake you are trying to switch to does not work obviously. Then you hit the classic situation where your flake is not committed or staged, so Nix refuses to see it. And instead of telling you that, it prints this abomination of error message "error: path '/nix/store/0ccnxa25whszw7mgbgyzdm4nqc0zwnm8-source/flake.nix' does not exist" (https://determinate.systems/blog/changelog-determinate-nix-331/#untrac… I would not wish learning Nix from zero on my worst enemy, and I say that as someone who uses nix-darwin, devShells, deploy-rs and so on every day. The UX/DX is really bad, but nothing else comes close to its capabilities. Sorry for rant but without flakes I would not make it.

A big problem with making an abstraction over CI providers is that they are, on the surface, very little more than wrappers around steps made up of small scripts, but that abstraction leaks like hell. So I think you would wind up needing to go quite high-level to make something that is useful here, but even if you do do this, the variance in runtime environment will make it very difficult to make sure things are relatively portable, and attempts to work around this will lead to problems (e.g. you could just wrap everything in Docker, but fetching large images on each CI invocation isn't really a good use of resources.) Let's say you have a project using CMake with vcpkg. Vcpkg has support for the GitHub Actions Cache API, so it can integrate very well into GHA and provide good performance for caching dependencies so they do not need to be built on each invocation. Doesn't seem too unreasonable, you could have a vcpkg+CMake plugin of some kind that tries to do the best thing for each CI provider. But, what version of vcpkg do you use? what version of CMake do you use? Vcpkg is essentially just a rolling-release Git repo, there's no specific version to use. But it would save a lot of time to make use of the vcpkg installation that already exists on GitHub Actions images. And obviously, a tool like CMake depends super heavily on the environment around it. A lot of people use the Ninja provider for better performance... but if you use it on Windows, you need to be careful:…

My first encounter with Nix was using it that way to get my favorite tools on the university computer lab without convincing the admins to install them for me. Today, some Steam Deck users are using Nix to supplement their console's desktop experience with familiar tools without the overhead of Flatpak or the risk of modifying the base system (in which case modifications are nuked on SteamOS updates anyhow). Determinate Systems did some work to enable and document that, and one YouTuber recently posted an intro/walkthrough of their docs as well. Video: https://m.youtube.com/watch?v=ttOs5iWgNzk Secondary documentation (YouTuber's blog): https://christitus.com/steamdeck-as-a-desktop/ Primary documentation by Determinate Systems: https://determinate.systems/posts/nix-on-the-steam-deck (Some of the work relevant here was done by folks outside of Determinate Systems as well. The installer workgroup is not exclusively DSers.) Sometimes it just fits a use case so much better than alternatives that it's an obvious choice.

> Nix has an install step to use a package Not true. See "Using Nix to run software with no installation steps" https://determinate.systems/posts/nix-run for example. This feature has been one of the main use cases of Nix. > Nix has an install step ... AppFS does not... I'm the author of AppFS.net... I appreciate the disclosure, as it helps readers (like me) to judge the merits of your claims, especially regarding AppFS vs other options, and whether those claims could be biased (due to differences in familiarity, for example). > I'm not sure what kind of disclosure is needed... Over Hacker News and other forums, when the author of a tool wants to promote their work (nothing wrong with this, I learnt a lot with such promotions) in the context of competing tools, the following disclosures are common: 1. Disclosure: I wrote AppFS. 2. Author of AppFS here. (Just like what you did.) 3. Shameless plug. (Note: I personally do not see this as a shame, but I just want to give examples of common disclosure styles in such contexsts.)

for future reference you should really consider installing it with the determinate nix installer [0] instead. it's multi-platform and among other things creates an install receipt so that changes can be painlessly reverted. [0] https://determinate.systems/nix-installer/

For context, Determinate is a startup made of the Nix guy and some of the senior community members. They explicitly support the Steam Deck (and used it as a test case to create their installer). https://determinate.systems/posts/nix-on-the-steam-deck/

> Wow, what can a Mac auto-update do that is worse than Windows blocking your screen for 10 minutes Rename random internal user accounts without informing the user, breaking many third-party package managers with an overnight upgrade? https://determinate.systems/posts/nix-support-for-macos-sequoia/ Oh, or it could depreciate an entire class of software you may-or-may-not use without any opportunity for replacement besides downgrading your Mac? https://support.apple.com/en-us/103076

Oh i've been using Nix on mac for quite a while. Not sure about the uninstall, but recently i did a fresh macbook install and used the Determinate Systems Nix Installer[1]. I haven't tried uninstalling, but installation was a joy by comparison to the traditional way (and poor documentation). [1]: https://determinate.systems/posts/determinate-nix-installer/

The installer does it all for you. Theres even graphical installer https://determinate.systems/posts/graphical-nix-installer/

I suggest the post author and you look into nu as the package build language. It's uniquely suited for this task, being a cross-platform shell[1] with real programming language features, data types, and using built-in uutils instead of relying on platform-dependent coreutils. It also limits mutability[2], favoring a more functional than imperative approach, which would at least theoretically help with reproducibility. A guy from Determinate Systems recently made an experiment on integrating nushell to nix and the results were positive. Take a look: https://determinate.systems/posts/nuenv/ 1: https://www.nushell.sh/ 2: https://www.nushell.sh/book/thinking_in_nu.html#variables-are-immutabl…

There are a few cases where Nix itself can break on macOS upgrades, but the recently released Survival Mode installer should mitigate that. https://determinate.systems/posts/nix-survival-mode-on-macos

Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on. We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't. [1]: https://determinate.systems/posts/determinate-nix-installer#the-future…

> How do you use Nix on a project, any tips? Combining nix with direnv is a popular combo for dev environments. Example: https://determinate.systems/posts/nix-direnv If you haven't worked with nix before, the quick start here is a good place to start https://zero-to-nix.com/

You might want to give the new installer by Determinate Systems a try: https://determinate.systems/posts/determinate-nix-installer

This is awesome, thanks for sharing so much detail. Btw one thing I noticed, the link to "Determinate Systems" was broken. I think this is the correct link: https://determinate.systems/posts/qemu-fix

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither did they want to ask me how to make something work with Nix, neither did they tell me they didn't want to learn Nix. In essence, I told them to set the project up with it, which they'd do (and which would be successful, at least initially), but forgot that I also had to sell them on it. In one case, a developer spent all weekend (of HIS time) uninstalling Nix and making things work using the "usual crap" (as I would call it), all because of an issue I could have fixed in probably 5 minutes if he had just reached out to me (which he did not, to my chagrin). The first time I heard them comment their true feelings on it was when I pushed back regarding this because I would have gladly helped... I've mentioned this on various Slacks to get feedback and people have basically said "you either insist on it and say it's the only supported developer-environment-defining framework, or you will lose control over it" /shrug 2) Developers really like to have control over their own machines (but I failed to assume they'd also want this control over the project dependencies,…