32 ms·

We want to make Nix better

223 points by biggestlou 4y ago

grhmc 4y ago
With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right direction.
- nbp 4y ago
  My thinking is that this is long overdue! I am working on a very large project where multiple solutions have been invented to solve problem which are all handled by Nix: - Bake in the repository the clone of the dependencies. - Compile the tool chain to create reproducible builds. - Create "artifact" builds, to avoid large recompilation times for many developers. - Use various tools to cache and distribute builds. - Use a bleeding-edge version of some dependencies. - Use Node, Java (Android), C++, Rust, … If only Nix were to run natively on Windows, this would check all the boxes.
  - bpye 4y ago
    There was some work being done to make Nix work on Windows [0] - but it might have fizzled out. I too would really love Nix to work on Windows. I already use it on both macOS and Linux and it’s great. [0] - https://github.com/nix-windows/nix https://github.com/nix-windows/nix
- tadfisher 4y ago
  I might suggest making a typed superset of Nix, basically adding record types and function signatures. That in itself would be a huge boon for tooling and interacting with nixpkgs. nixpkgs describes a huge and varied meta-API for derivations in various build ecosystems, which makes it hard to use because you ultimately need to dive into source code.
  - yewenjie 4y ago
    https://github.com/tweag/nickel https://github.com/tweag/nickel
  - grhmc 4y ago
    We've heard this feedback pretty frequently. We have a few ideas of ways to add some types to Nix in place. I think even simple naive approaches would add a lot of safety and improve the usability of Nix. However, one of the bigger problems here is the general API design of Nixpkgs. Most of the function interfaces use some named parameters and then use `...` to accept any additional parameters. All of those then get passed down to some other function, and on and on. This makes a mess! It is hard to tell what functions use what parameters, and none of them can restrict their interface. We could see some significant DX here by creating smaller, more specific interfaces that actually restrict their inputs.
    - mikepurvis 4y ago
      I think the biggest win with some progressive typing would be better error diagnostics. Right now the errors are horrifyingly bad in many cases, puking out massive recursive stack traces that have nothing to do with the real problem. Being able to pinpoint exactly where the square peg is going into a round hole would be amazing.
  - tazjin 4y ago
    Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact, deriving the full set of potentially relevant type constraints is only possible at runtime due to how the import system works and the shape of most expressions. If you pick a single file from nixpkgs without context, you can't get much information from it at all (other than a lot of unknown types being passed to things that accept an unknown type) - it's only in the context of an evaluation of a graph node that uses that file that you can infer anything meaningful about it (and even then that information is only relevant in that context). I think what people actually want is a way to derive more sensible documentation information from the code so that the various builders etc. could have checked documentation pages, as well as tooling for auto-completing members of attribute sets, names of (formals) function arguments and so on. fwiw, there's an alternative implementation of the Nix language[0] that we (TVL[1]) are slowly open-sourcing at the moment, and we're aiming to design it in such a way that things like an LSP can be implemented on top of it, and to be able to dump out static information from a context that can help with documentation etc. [0]: https://cs.tvl.fyi/depot/-/tree/tvix/eval https://cs.tvl.fyi/depot/-/tree/tvix/eval [1]: https://tvl.fyi/ https://tvl.fyi/ [2]: Yes, I'm aware that Nix is turing-complete, but surely nobody would write a web framework[3] and HTML templater[4] in it. [3]: https://cs.tvl.fyi/depot/-/blob/web/bubblegum/README.md https://cs.tvl.fyi/depot/-/blob/web/bubblegum/README.md [4]: https://cl.tvl.fyi/c/depot/+/3410 https://cl.tvl.fyi/c/depot/+/3410
- setheron 4y ago
  I wish this blog post had more meat to it. It was pretty minimal on information. This is also due to the fact that I tend to value Graham's posts highly :)
  - biggestlou 4y ago
    Consider this post more of a "hello world." Substance is on the way :)
- mamcx 4y ago
  My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/databases/postgresql.nix https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/NixOS/comments/x46w98/why_new_user_is_not_added/ https://www.reddit.com/r/NixOS/comments/x46w98/why_new_user_... The thing is: Nixos not tell what is doing. `verbose` is too much noise. What I wish now is something like: nix change nothing (if my changes somehow don't do anything, like in my issue) nix setup users... nix setup postgresql
  - Bolkan 4y ago
    Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.
    - colordrops 4y ago
      You can use agenix for secrets management. You can store all secrets encrypted with your SSH key in public config. The only non functional part is installing your SSH key, which is probably not a bad thing.
    - kaba0 4y ago
      Are you using home-manager for that?
  - colordrops 4y ago
    I'm looking at your second link, and it's not really that bad if you are familiar with nix. It's a standard pattern for a package with options. Mostly a long enumerated list, not any different from a long enumerated list of the postgres options themselves. The great thing about it is that it's a single DSL, instead of 10,000 DSLs, one for each package you install. I do think command line options to do what you ask would be nice, but in order to keep the declarative reprudicibility you get with nix, those commands would need to operate on nix config rather than the system itself. They could update the config then update the system based on the config, so it could look like one step even though it is two behind the scenes.
- flurie 4y ago
  Hi, Graham, I have a few questions. Does Eelco's departure from Tweag have any impact on Nickel as a possible replacement for nix? There are lots of fragmented attempts at making nix easier/more immediately valuable/lower barrier to entry. Some of these are personal projects, some are businesses. Some of these just make nix easier, and some attempt to put something in between nix and the user. I'm thinking about things like Cachix, Flox, and divnix (formerly devos). How do you see your work interacting with these? One of my barriers to adoption at work has been ensuring maintenance continuity. That's always going to be the case for tools that aren't ubiquitous, but I worry with nix that teams without my assistance will revert to other tools they know better, even if I've invested a good bit of time in teaching them enough to keep things going. Do you seek to address that?
ianai 4y ago
I hope this goes the way of RedHat/SUSE. i.e. The corporate side of a FOSS project so that contracts can be signed for appropriate purposes, etc.
ridiculous_fish 4y ago
I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the recommended multi-user install, should I have just used the single user mode instead?
- nodejsthrowaway 4y ago
- edolstra 4y ago
  It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
  - qudat 4y ago
    Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.
    - kaba0 4y ago
      It’s not actually hardcoded, but you would have to compile everything from scratch as the hash would depend on that as well, throwing out the whole binary cache.
      - wmertens 4y ago
        Actually, there's quite a few hard-coded references to /nix in nixpkgs I believe. It's possible but a little more work than just changing the prefix.
Jeaye 4y ago
Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning C# or Rust can use LSP); a better type system for Nix would help here 3. Better documentation for practical things like "Using Nix to manage the dependencies and package a C++ program using Meson", rather than having people piece this together from a bunch of disparate docs 4. A much better CLI UX than `nix-env -qa` and the like (this is ongoing and experimental, but even that broke recently, causing lots of confusion; now it requires `nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs`) 5. To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so. I feel like Nix folks have been focused so long on solving the tough problems of declarative, deterministic packaging that they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else. Perhaps like the early days of Git. I do really hope Nix succeeds in this, though; I've been using it, or it's been using me, for several years. [1] and [2] for more info. [1]: https://blog.jeaye.com/2015/11/24/nixos/ https://blog.jeaye.com/2015/11/24/nixos/ [2]: https://blog.jeaye.com/2017/07/30/nixos-revisited/ https://blog.jeaye.com/2017/07/30/nixos-revisited/
- Bolkan 4y ago
  What nix needs more than anything is a centralized repository containing recipes for running all the different kinds of programs, as nic files. ie a dockerhub alternative.
  - xyzzy_plugh 4y ago
    nixpkgs?
    - 4y ago
rgoulter 4y ago
I agree with the preamble and the "our mission" stuff. I wish them success at bringing the benefits of nix to more users, but without it being limited to enthusiasts, and people who can afford to deal with rough edges. The "external dependencies" thing shows how Nix can be a tough sell to those who don't click with it. I'd say that the other solutions are: - a README which has a bunch of "apt-get install" commands you can copy-paste from, - a "setup.sh" script that installs things, - a container or VM image with the toolchain setup, - or a tool like asdf. IMO, Nix is a much nicer solution than these other options, and has the benefits, avoids the downsides of these (but an entirely different set of downsides).
- wizwit999 4y ago
  How about Bazel, doesn't it solve the same issues?
  - rgoulter 4y ago
    Both Bazel and Nix have some powerful features to them. (Though, oddly, they don't quite mix). I think they both also have downsides where, if your software does things in ways they don't like, it's difficult to use them. -- And, your team is going to have a tough time using the tool without sufficient expertise. As I understand it, Bazel's emphasis is more about compilation, where the big win is building projects where you've got a team big enough (& a project complex enough) that dealing with Bazel saves more time than it costs. Whereas with Nix.. I think one good use case is "declare & lock the dependencies for this toy project", which then allows picking the project up without having to update your code following updates to the system package manager.
rrgok 4y ago
Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed NixOS and it took me 10min to install a whole OS with Sway, Neovim and some other tools. I guess I'm doing something wrong. But, on MacOS, nixpkgs was not a pleasant experience at all.
- rgoulter 4y ago
  > 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. It's the same as homebrew: If there's a cached binary already, it will download the cached binary. If not, it will fetch the source and build it. The QMK nix shell needs different GCCs for different targets. For the QMK shell.nix specifically, you can disable the targets you don't need (e.g. if you don't use a teensy board).
  - rrgok 4y ago
    That makes sense. Is there a `nix-shell` option that outputs which packages will be compiled from source and which will get a precompiled binary? Something like `nix-shell --dry-run`? I have to learn more about the nix language, but looking at the shell.nix seems that I have comment/remove lines from 25 to 30 according to my board.
    - ParetoOptimal 4y ago
      > Something like `nix-shell --dry-run`? Exactly that? Lol :)
      - rrgok 4y ago
        Really? It is not written in the official nix-shell manual https://nixos.org/manual/nix/stable/command-ref/nix-shell.html https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht... I still will try when I get to my macbook. Thank you!
zuzuleinen 4y ago
"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also started working on an initiative to improve Nix documentation which was spread all over the places. [1] https://bob.build/ https://bob.build/
- biggestlou 4y ago
  Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts. Suggestion: make Bob installable with Nix!
  - zuzuleinen 4y ago
    Thanks for the suggestion! It makes sense to have it on Nixpkgs collection since anyway you need to install Nix alongside bob Already created an issue :) https://github.com/benchkram/bob/issues/193 https://github.com/benchkram/bob/issues/193
- yewenjie 4y ago
  How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.
  - zuzuleinen 4y ago
    I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management
shiryel 4y ago
I love nix, I've been using it for the last 2 years, I have a very stable setup from these 2 years of effort [0], and I just can't recommend Nix for Linux beginners, why? It's not because of the nix language, It's not because of the CLI, it's because everything is scattered, you have to consult many places to find out how to do things with Nix, here is an example: Usually, when I need a new complex program, like Steam, I first check the system-wide configuration [1], the wiki [2] and the package list [3], if I just want it on my user, I need to check if Home Manager has an option [4], if it doesn't, I can try using the "home.packages" option. Now, if I need to override something on the package, I need to remember how to do it with [5] [6] (while checking the source code for the package in parallel to find the options). And then sometimes, on very rare occasions, I need to fine tune something with the nix language, so I need to check the builtins/lib docs [7], but some builtins are not there, so I need to either use nix-doc [8] or find the docs inside the code-bases [9] [10] (they are split between both repos) For me, this is one of the main pain points of using Nix / NixOS that needs to be solved. [0] - https://github.com/shiryel/nixos-dotfiles https://github.com/shiryel/nixos-dotfiles [1] - https://search.nixos.org/options https://search.nixos.org/options [2] - https://nixos.wiki/wiki/Steam https://nixos.wiki/wiki/Steam [3] - https://search.nixos.org/packages https://search.nixos.org/packages [4] - https://mipmip.github.io/home-manager-option-search/ https://mipmip.github.io/home-manager-option-search/ [5] - https://nixos.org/manual/nixos/stable/#sec-customising-packa https://nixos.org/manual/nixos/stable/#sec-customising-packa... [6] - https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag... [7] - https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html [8] - https://github.com/lf-/nix-doc https://github.com/lf-/nix-doc [9] - https://github.com/NixOS/nix https://github.com/NixOS/nix [10] - https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
setheron 4y ago
Funny enough I introduced Nix to our company which was acquired by Google -- so Google has software leveraging Nix. (I got Google to in fact sponsor Nix which was nice too. A small amount but it was meaningful to me).
mixedCase 4y ago
Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with. The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support. I don't know if a good enough hostable language exists or if it should be a new version of Nixlang, but almost every single annoying problem that makes me go "Nix is getting in my way" can be traced back to the lack of a good, powerful type system leading to a house of cards situation whether it comes from nixpkgs or entirely of my own making.
- jhillyerd 4y ago
  I think this is true for Nix in the deployment/ops space, where debugging a broken build can be very frustrating. Language improvements are going to be less useful for app developers, the Flake learning curve is not going to get better with a type system. Perhaps something like heroku buildpaks (https://github.com/railwayapp/nixpacks https://github.com/railwayapp/nixpacks ?) would help devs get on the Nix train.
- tikhonj 4y ago
  The problem is that we need not just a language like that, but a version of Nixpkgs-the-codebase designed for that language with corresponding sensibilities. And that's a much bigger obstacle than coming up with a language!
- nextaccountic 4y ago
  Can Dhall be that language?
  - emptysongglass 4y ago
    How does Dhall compare to Nickel?
Arcuru 4y ago
Since Eelco (often treated as Nix's BDFL) and Graham (also very prominent in the Nix community) are involved hopefully this group will actually be able to make traction on some of these issues. This is not even close to the first of these posts saying "we're going to help make Nix more user friendly!", but maybe this group has a chance of making changes to the Nix ecosystem since they can just approve it themselves. I've had concerns about Nix's governance in the past but it sounds like they may be going in the right direction, so I'm excited to see what they're planning.
skybrian 4y ago
The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. For example, esbuild is written in Go, which is compiled to a different binary for each system. The NPM for esbuild has 21 optional dependencies, one for each binary that it makes available. A post-install script [1] chooses which dependency to install. It seems like a lot of work for the maintainer? But most users don't need to care. It probably helps that the Go SDK builds static binaries. [1] https://github.com/evanw/esbuild/blob/master/lib/npm/node-install.ts https://github.com/evanw/esbuild/blob/master/lib/npm/node-in...
- ParetoOptimal 4y ago
  > The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. This complicates working on node projects with nix in my experience. Is there a way to tell npm "no, just use my binary"? Best i've found is letting npm download it and then overwriting the npm binary with the nix one in a postinstall script. Why you ask? Npm doesn't always have an aarch64 or arm32 binary. Nix being a source based package manager typically does support it or at least makes it possible by overriding build/configure options.
  - skybrian 4y ago
    If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users. Also, I wonder if nix would be a suitable tool for generating npm packages that contain binaries? Maybe this is a way for people to benefit from nix without actually using it.
    - rgoulter 4y ago
      > If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users. The "I have a binary already, just use this one" is in response to the problems NixOS users face dealing with helpful software like this. NixOS doesn't provide shared libraries in the standard locations (for good reasons). Binaries that tools like NPM download will link against shared libraries in the standard location. It's not really a question of "providing the binaries would help", because it's about assumptions of where the shared libraries are.
gavinhoward 4y ago
Disclaimer: I'm working on a build system that will eventually do what Nix does but make it much easier to use. If they do manage to create a system where Nix is hidden, and end users never have to directly touch it, I think this could work and make my work never see the light of day. But I have my doubts that they will be able to do that, and it boils down to one simple reason: declarative is not powerful enough. Don't get me wrong, for 90%, possibly more, of use cases, it's enough. And it is preferable to keep things declarative as long as possible, so much so that my build system will have a way of restricting itself to purely declarative code when possible (and will error otherwise). However, when more power is necessary, it is required; it is not possible, by the definition of Turing-completeness and declarative, to do the same thing with a declarative language that can be done with a Turing-complete language. So when that power is missing, the only option is to work around it. This is why Nix is really just a front for bash. For all of its faults, at least bash is Turing-complete. But this fact means that there will be things that Nix will fail to do on its own. I suspect this means that the abstraction around Nix will always be leaky. Maybe it won't be unacceptably leaky, but I'm not very hopeful. I think Nix would be better served by doing the following: 1. Rewriting the language. This would require an auto-transformer to the new language in order to not throw away the entirety of nixpkgs, but transforming a declarative language to a Turing-complete one is easy. 2. Spend gobs of time on user experience. Make the usual commands short, easy to remember, and easy to use with few options. Make usual things easy and powerful things safe. For example, to make a powerful thing safe, make sure that screwing it up will not screw up their system. 3. But not only should they be safe, they should feel safe, giving users every opportunity to back out without consequences. This is where git goes wrong: it does not feel safe, so users are scared of it. [0] I believe Nix is the same way, even though it is safer than git. 4. Spend gobs of time on documentation. Use Fred Rogers' list of rules for talking with children [1] in each piece of documentation. This will make it easier to avoid the trap of not explaining something the user needs because the writer forgot that they didn't know it. In essence, the documentation should treat new users as Fred Rogers treated children: ignorant, but capable. 5. The documentation also needs to have a different focus. Instead of focusing on how great Nix is, it should focus on helping users get stuff done. Nix enthusiasts should be able to say, "Oh, you want to set up a development environment for your project? Great, go to such-and-such tutorial. It will tell you exactly how to do that even if you don't have Nix installed." This should be done for as many use cases as people have, including less common ones. Some examples: using Nix as a build system, using Nix to install multiple versions of glibc and how to switch between them, using Nix to set up systemd, using Nix to replace a Docker container in production, using Nix to distribute builds, etc. [0]: https://xkcd.com/1597/ https://xkcd.com/1597/ [1]: https://www.mentalfloss.com/article/547536/mr-rogers-rules-for-talking-to-kids https://www.mentalfloss.com/article/547536/mr-rogers-rules-f...
oxff 4y ago
Make the documentation up to the modern standards. If I have to open a single random blog or Github repository to find out what to do and piece it together like a puzzle - it is impossible to adapt at organizational scale. It is also complex enough to require a modern Language Server.
- fancyfish 4y ago
  This has been my experience also. I finished the Nix Pills, and got some personal Python/Haskell projects built using nixpkgs by following the nixpkgs language-specific documentation, but anything off the beaten path is going to involve lots of blog posts and clicking through source code. For example in the Haskell world there are so many blog posts that go in different directions from the nixpkgs docs, using flakes, haskell.nix, etc. We adopted it in an organization of ~100 engineers, and the only way it’s been possible is having a full-time Nix team writing custom Nix functions specific for our environment and projects. That team also does “Nix help desk” work for one-off questions. Once it works, it does a great job of hermetic builds, easy Docker images, easy to add cross-repo dependencies mixing C++/Python etc. But there are too many rough edges I can’t recommend it in the general case over Dockerfiles, Bazel or language-specific tooling, Cmake, etc. Pick something simpler, ideally whatever is popular for your language.
beermonster 4y ago
Is it Nix or NixOS?
- qbasic_forever 4y ago
  Both exist. Nix is a functional language for describing how software is built. Nix is also a package manager of sorts that installs and manages software built with its language. NixOS is an operating system that is described entirely by a nix language configuration file that builds a bootable linux-based OS using nix language packages.
- grumbel 4y ago
  Nix is a package manager & programming language that you can install on any Linux or MacOS to manage software. NixOS is a bootable OS build on top of Nix. Nixpkgs is the default package collection used by both Nix and NixOS.
anderspitman 4y ago
For the first time in about 8 years an Arch update rendered my OS unbootable last week. I'd had graphics issues once or twice but this time it just hung in systemd somewhere. Still don't know what happened. Rolled all packages back about a month and that worked, but I'll need to update eventually. I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom side. Chances are I'll just do a fresh Arch install or maybe try Debian rolling. These days I like to install almost all software and libraries by hand in my home directory. All I really want is a solid system that basically boots fresh then loads my home directory. Maybe I should do a net boot of some sort? Any other suggestions?
- iopq 4y ago
  I mean, I just add packages to the list and some configuration options. If you only need it as a user it's fairly simple.
- Daegalus 4y ago
  you can try something like Kinoite or Silverblue from fedora. you can also manage tools with asdf if it makes it easier. I personally run Fedora + Flatpaks + asdf and it covers everything, and is stable, up to date, and has a new release every 6 months. it feels midway between a rolling release and. apoint release
- jcynix 4y ago
  I just started to experiment with EndeavourOS, a prepackaged version of Arch. Looks nice so far. https://endeavouros.com/about-us/ https://endeavouros.com/about-us/
- sph 4y ago
  Eh, I'd just use Silverblue. You get the benefits of immutability, without having to learn a new language and weird tools to manage your workstation. I ain't got time for any of that.
- Sugimot0 4y ago
  Just a heads up, the issue was likely grub, grub had a breaking change for certain EFI devices. You can check arch news etc for more info. I had to chroot and fix my laptop the other day cause it was stuck boot looping after I upgraded.
ontouchstart 4y ago
I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago. I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate Systems. Don’t get distracted by language features and syntactic sugars. If it works, people will learn.
- JustLurking2022 4y ago
  I've worked with large scale monorepos in FAANG - as a rule, they all suck. Eventually you always end up in this place where you have to understand, and be prepared to debug the entire universe just to build hello world.
  - ontouchstart 4y ago
    Totally agree. For complicated system, this essential complexity won't go away no matter how you make the UX "friendly". But good tooling will help users grow to understand the challenge of the problems as well as to appreciate the power of the solution. For people who are really interested in the solution, they will eventually dive deeper: https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
  - deleted 4y ago
    [deleted]
lykahb 4y ago
The name Nix is used for the language, package system, and sometimes the whole ecosystem. There is a recent post that tells the difference https://www.haskellforall.com/2022/08/stop-calling-everything-nix.html https://www.haskellforall.com/2022/08/stop-calling-everythin... Knowing functional programming helps but Nix still is a hard language to learn. I have a lot of Haskell experience but the Nix language was very confusing for me. At first I couldn't even tell a variable name from a keyword (it is a convention to call variables "self" and "super" in some contexts). The Nix language has been created for research in build systems and has evolved over a long time, so it has accumulated quite a lot of idiosyncrasies and cruft. I hope that a simpler typed language like https://github.com/tweag/nickel https://github.com/tweag/nickel replaces it.
- kaba0 4y ago
  I believe blaming the language is misguided. The problem is that nixpkgs’ constructs are not well documented, or not yet stable. It would be a problem in any language (you can’t expect someone to feel familiar in a new codebase, and nixpkgs is essentially that).
  - lykahb 4y ago
    Yeah, the conventions of nixpkgs are a much bigger obstacle than the language syntax. The language lacks static typing. Also, it is a common convention to create attribute sets crafted for logic that has indirect hard-to-follow links to module where the set is defined. This makes it hard to develop tooling like linters or LSP implementations.
AprilArcus 4y ago
Just let me a pin a single package to a version number, for the love of God.
- kaba0 4y ago
  What does that version mean? What compile flags was it compiled with, which compiler, etc?
- grumbel 4y ago
  You can do that with something like this: pkgs.yourpackage.overrideAttrs { prev: { src = fetchurl { url = "..."; sha256 = "..."; }; }} Bit annoying that you have to specific the full URL instead of just the 'version' number, but it'll work. With flakes you can just add a 'ref' or 'rev' to the URL: nix run "github:juser/software?ref=v0.4.1" If you want to override a package dependency across 'override'.
dd_ 4y ago
As someone who has been using NixOS for a couple of years now, I really want to say how appreciative I am of everybody for making noticeable improvements to the system on a somewhat regular basis. The nix command keeps on adding great new features like flake templates and bundling as well as just being more user friendly (error messages, actionable hints, etc.) Additionally, tools like nix-ld [1] make nix more usable than ever with software from external sources. Things just keep on getting better for NixOS users! Despite the reputation, I feel that NixOS or some derivative of it has the power to become the best distribution for non-technical users in the long run. What NixOS has done is effectively built an interface to every component of a modern Linux system, all that needs to be built is a user application to take advantage of it. Of course, there still needs be some improvements in Nix itself for it to blossom into its final form, but I really see a path to greatness here. I have often thought about creating a simple unified Win2K-esq or BeOS-like X11 WM/DE specifically for NixOS but unfortunately I lack the time/motivation. [1] https://github.com/Mic92/nix-ld https://github.com/Mic92/nix-ld
- colordrops 4y ago
  Yes, I could imagine a very locked down opinionated distro built on top of Nix that completely abstracts away all of it and makes it work somewhat like Ubuntu with some prepared nix templates/metaprogramming to automatically generate config. Over time more of the Nix functionality could be exposed through UI or more friendly cli tools as best practices and nix itself evolve, allowing the distro to remain friendly to non-technical users while opening up it's true powers to them. It wouldn't be able to handle arbitrary manual changes to config at the beginning, so either there would always be a protected generated config region of the whole config and the distro would remain relatively standardized, or an alternative evolution would be a low-code user friendly UI that could map to any possible nix config.

223 points by biggestlou 4y ago

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right direction.

nbp 4y ago
My thinking is that this is long overdue! I am working on a very large project where multiple solutions have been invented to solve problem which are all handled by Nix: - Bake in the repository the clone of the dependencies. - Compile the tool chain to create reproducible builds. - Create "artifact" builds, to avoid large recompilation times for many developers. - Use various tools to cache and distribute builds. - Use a bleeding-edge version of some dependencies. - Use Node, Java (Android), C++, Rust, … If only Nix were to run natively on Windows, this would check all the boxes.
- bpye 4y ago
  There was some work being done to make Nix work on Windows [0] - but it might have fizzled out. I too would really love Nix to work on Windows. I already use it on both macOS and Linux and it’s great. [0] - https://github.com/nix-windows/nix https://github.com/nix-windows/nix
tadfisher 4y ago
I might suggest making a typed superset of Nix, basically adding record types and function signatures. That in itself would be a huge boon for tooling and interacting with nixpkgs. nixpkgs describes a huge and varied meta-API for derivations in various build ecosystems, which makes it hard to use because you ultimately need to dive into source code.
- yewenjie 4y ago
  https://github.com/tweag/nickel https://github.com/tweag/nickel
- grhmc 4y ago
  We've heard this feedback pretty frequently. We have a few ideas of ways to add some types to Nix in place. I think even simple naive approaches would add a lot of safety and improve the usability of Nix. However, one of the bigger problems here is the general API design of Nixpkgs. Most of the function interfaces use some named parameters and then use `...` to accept any additional parameters. All of those then get passed down to some other function, and on and on. This makes a mess! It is hard to tell what functions use what parameters, and none of them can restrict their interface. We could see some significant DX here by creating smaller, more specific interfaces that actually restrict their inputs.
  - mikepurvis 4y ago
    I think the biggest win with some progressive typing would be better error diagnostics. Right now the errors are horrifyingly bad in many cases, puking out massive recursive stack traces that have nothing to do with the real problem. Being able to pinpoint exactly where the square peg is going into a round hole would be amazing.
- tazjin 4y ago
  Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact, deriving the full set of potentially relevant type constraints is only possible at runtime due to how the import system works and the shape of most expressions. If you pick a single file from nixpkgs without context, you can't get much information from it at all (other than a lot of unknown types being passed to things that accept an unknown type) - it's only in the context of an evaluation of a graph node that uses that file that you can infer anything meaningful about it (and even then that information is only relevant in that context). I think what people actually want is a way to derive more sensible documentation information from the code so that the various builders etc. could have checked documentation pages, as well as tooling for auto-completing members of attribute sets, names of (formals) function arguments and so on. fwiw, there's an alternative implementation of the Nix language[0] that we (TVL[1]) are slowly open-sourcing at the moment, and we're aiming to design it in such a way that things like an LSP can be implemented on top of it, and to be able to dump out static information from a context that can help with documentation etc. [0]: https://cs.tvl.fyi/depot/-/tree/tvix/eval https://cs.tvl.fyi/depot/-/tree/tvix/eval [1]: https://tvl.fyi/ https://tvl.fyi/ [2]: Yes, I'm aware that Nix is turing-complete, but surely nobody would write a web framework[3] and HTML templater[4] in it. [3]: https://cs.tvl.fyi/depot/-/blob/web/bubblegum/README.md https://cs.tvl.fyi/depot/-/blob/web/bubblegum/README.md [4]: https://cl.tvl.fyi/c/depot/+/3410 https://cl.tvl.fyi/c/depot/+/3410
setheron 4y ago
I wish this blog post had more meat to it. It was pretty minimal on information. This is also due to the fact that I tend to value Graham's posts highly :)
- biggestlou 4y ago
  Consider this post more of a "hello world." Substance is on the way :)
mamcx 4y ago
My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/databases/postgresql.nix https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/NixOS/comments/x46w98/why_new_user_is_not_added/ https://www.reddit.com/r/NixOS/comments/x46w98/why_new_user_... The thing is: Nixos not tell what is doing. `verbose` is too much noise. What I wish now is something like: nix change nothing (if my changes somehow don't do anything, like in my issue) nix setup users... nix setup postgresql
- Bolkan 4y ago
  Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.
  - colordrops 4y ago
    You can use agenix for secrets management. You can store all secrets encrypted with your SSH key in public config. The only non functional part is installing your SSH key, which is probably not a bad thing.
  - kaba0 4y ago
    Are you using home-manager for that?
- colordrops 4y ago
  I'm looking at your second link, and it's not really that bad if you are familiar with nix. It's a standard pattern for a package with options. Mostly a long enumerated list, not any different from a long enumerated list of the postgres options themselves. The great thing about it is that it's a single DSL, instead of 10,000 DSLs, one for each package you install. I do think command line options to do what you ask would be nice, but in order to keep the declarative reprudicibility you get with nix, those commands would need to operate on nix config rather than the system itself. They could update the config then update the system based on the config, so it could look like one step even though it is two behind the scenes.
flurie 4y ago
Hi, Graham, I have a few questions. Does Eelco's departure from Tweag have any impact on Nickel as a possible replacement for nix? There are lots of fragmented attempts at making nix easier/more immediately valuable/lower barrier to entry. Some of these are personal projects, some are businesses. Some of these just make nix easier, and some attempt to put something in between nix and the user. I'm thinking about things like Cachix, Flox, and divnix (formerly devos). How do you see your work interacting with these? One of my barriers to adoption at work has been ensuring maintenance continuity. That's always going to be the case for tools that aren't ubiquitous, but I worry with nix that teams without my assistance will revert to other tools they know better, even if I've invested a good bit of time in teaching them enough to keep things going. Do you seek to address that?

ianai 4y ago

I hope this goes the way of RedHat/SUSE. i.e. The corporate side of a FOSS project so that contracts can be signed for appropriate purposes, etc.

ridiculous_fish 4y ago

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the recommended multi-user install, should I have just used the single user mode instead?

nodejsthrowaway 4y ago
edolstra 4y ago
It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
- qudat 4y ago
  Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.
  - kaba0 4y ago
    It’s not actually hardcoded, but you would have to compile everything from scratch as the hash would depend on that as well, throwing out the whole binary cache.
    - wmertens 4y ago
      Actually, there's quite a few hard-coded references to /nix in nixpkgs I believe. It's possible but a little more work than just changing the prefix.

Jeaye 4y ago

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning C# or Rust can use LSP); a better type system for Nix would help here 3. Better documentation for practical things like "Using Nix to manage the dependencies and package a C++ program using Meson", rather than having people piece this together from a bunch of disparate docs 4. A much better CLI UX than `nix-env -qa` and the like (this is ongoing and experimental, but even that broke recently, causing lots of confusion; now it requires `nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs`) 5. To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so. I feel like Nix folks have been focused so long on solving the tough problems of declarative, deterministic packaging that they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else. Perhaps like the early days of Git. I do really hope Nix succeeds in this, though; I've been using it, or it's been using me, for several years. [1] and [2] for more info. [1]: https://blog.jeaye.com/2015/11/24/nixos/ https://blog.jeaye.com/2015/11/24/nixos/ [2]: https://blog.jeaye.com/2017/07/30/nixos-revisited/ https://blog.jeaye.com/2017/07/30/nixos-revisited/

Bolkan 4y ago
What nix needs more than anything is a centralized repository containing recipes for running all the different kinds of programs, as nic files. ie a dockerhub alternative.
- xyzzy_plugh 4y ago
  nixpkgs?
  - 4y ago

rgoulter 4y ago

I agree with the preamble and the "our mission" stuff. I wish them success at bringing the benefits of nix to more users, but without it being limited to enthusiasts, and people who can afford to deal with rough edges. The "external dependencies" thing shows how Nix can be a tough sell to those who don't click with it. I'd say that the other solutions are: - a README which has a bunch of "apt-get install" commands you can copy-paste from, - a "setup.sh" script that installs things, - a container or VM image with the toolchain setup, - or a tool like asdf. IMO, Nix is a much nicer solution than these other options, and has the benefits, avoids the downsides of these (but an entirely different set of downsides).

wizwit999 4y ago
How about Bazel, doesn't it solve the same issues?
- rgoulter 4y ago
  Both Bazel and Nix have some powerful features to them. (Though, oddly, they don't quite mix). I think they both also have downsides where, if your software does things in ways they don't like, it's difficult to use them. -- And, your team is going to have a tough time using the tool without sufficient expertise. As I understand it, Bazel's emphasis is more about compilation, where the big win is building projects where you've got a team big enough (& a project complex enough) that dealing with Bazel saves more time than it costs. Whereas with Nix.. I think one good use case is "declare & lock the dependencies for this toy project", which then allows picking the project up without having to update your code following updates to the system package manager.

rrgok 4y ago

Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed NixOS and it took me 10min to install a whole OS with Sway, Neovim and some other tools. I guess I'm doing something wrong. But, on MacOS, nixpkgs was not a pleasant experience at all.

rgoulter 4y ago
> 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. It's the same as homebrew: If there's a cached binary already, it will download the cached binary. If not, it will fetch the source and build it. The QMK nix shell needs different GCCs for different targets. For the QMK shell.nix specifically, you can disable the targets you don't need (e.g. if you don't use a teensy board).
- rrgok 4y ago
  That makes sense. Is there a `nix-shell` option that outputs which packages will be compiled from source and which will get a precompiled binary? Something like `nix-shell --dry-run`? I have to learn more about the nix language, but looking at the shell.nix seems that I have comment/remove lines from 25 to 30 according to my board.
  - ParetoOptimal 4y ago
    > Something like `nix-shell --dry-run`? Exactly that? Lol :)
    - rrgok 4y ago
      Really? It is not written in the official nix-shell manual https://nixos.org/manual/nix/stable/command-ref/nix-shell.html https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht... I still will try when I get to my macbook. Thank you!

zuzuleinen 4y ago

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also started working on an initiative to improve Nix documentation which was spread all over the places. [1] https://bob.build/ https://bob.build/

biggestlou 4y ago
Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts. Suggestion: make Bob installable with Nix!
- zuzuleinen 4y ago
  Thanks for the suggestion! It makes sense to have it on Nixpkgs collection since anyway you need to install Nix alongside bob Already created an issue :) https://github.com/benchkram/bob/issues/193 https://github.com/benchkram/bob/issues/193
yewenjie 4y ago
How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.
- zuzuleinen 4y ago
  I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management

shiryel 4y ago

I love nix, I've been using it for the last 2 years, I have a very stable setup from these 2 years of effort [0], and I just can't recommend Nix for Linux beginners, why? It's not because of the nix language, It's not because of the CLI, it's because everything is scattered, you have to consult many places to find out how to do things with Nix, here is an example: Usually, when I need a new complex program, like Steam, I first check the system-wide configuration [1], the wiki [2] and the package list [3], if I just want it on my user, I need to check if Home Manager has an option [4], if it doesn't, I can try using the "home.packages" option. Now, if I need to override something on the package, I need to remember how to do it with [5] [6] (while checking the source code for the package in parallel to find the options). And then sometimes, on very rare occasions, I need to fine tune something with the nix language, so I need to check the builtins/lib docs [7], but some builtins are not there, so I need to either use nix-doc [8] or find the docs inside the code-bases [9] [10] (they are split between both repos) For me, this is one of the main pain points of using Nix / NixOS that needs to be solved. [0] - https://github.com/shiryel/nixos-dotfiles https://github.com/shiryel/nixos-dotfiles [1] - https://search.nixos.org/options https://search.nixos.org/options [2] - https://nixos.wiki/wiki/Steam https://nixos.wiki/wiki/Steam [3] - https://search.nixos.org/packages https://search.nixos.org/packages [4] - https://mipmip.github.io/home-manager-option-search/ https://mipmip.github.io/home-manager-option-search/ [5] - https://nixos.org/manual/nixos/stable/#sec-customising-packa https://nixos.org/manual/nixos/stable/#sec-customising-packa... [6] - https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag... [7] - https://teu5us.github.io/nix-lib.html https://teu5us.github.io/nix-lib.html [8] - https://github.com/lf-/nix-doc https://github.com/lf-/nix-doc [9] - https://github.com/NixOS/nix https://github.com/NixOS/nix [10] - https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs

setheron 4y ago

Funny enough I introduced Nix to our company which was acquired by Google -- so Google has software leveraging Nix. (I got Google to in fact sponsor Nix which was nice too. A small amount but it was meaningful to me).

mixedCase 4y ago

Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with. The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support. I don't know if a good enough hostable language exists or if it should be a new version of Nixlang, but almost every single annoying problem that makes me go "Nix is getting in my way" can be traced back to the lack of a good, powerful type system leading to a house of cards situation whether it comes from nixpkgs or entirely of my own making.

jhillyerd 4y ago
I think this is true for Nix in the deployment/ops space, where debugging a broken build can be very frustrating. Language improvements are going to be less useful for app developers, the Flake learning curve is not going to get better with a type system. Perhaps something like heroku buildpaks (https://github.com/railwayapp/nixpacks https://github.com/railwayapp/nixpacks ?) would help devs get on the Nix train.
tikhonj 4y ago
The problem is that we need not just a language like that, but a version of Nixpkgs-the-codebase designed for that language with corresponding sensibilities. And that's a much bigger obstacle than coming up with a language!
nextaccountic 4y ago
Can Dhall be that language?
- emptysongglass 4y ago
  How does Dhall compare to Nickel?

Arcuru 4y ago

Since Eelco (often treated as Nix's BDFL) and Graham (also very prominent in the Nix community) are involved hopefully this group will actually be able to make traction on some of these issues. This is not even close to the first of these posts saying "we're going to help make Nix more user friendly!", but maybe this group has a chance of making changes to the Nix ecosystem since they can just approve it themselves. I've had concerns about Nix's governance in the past but it sounds like they may be going in the right direction, so I'm excited to see what they're planning.

skybrian 4y ago

The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. For example, esbuild is written in Go, which is compiled to a different binary for each system. The NPM for esbuild has 21 optional dependencies, one for each binary that it makes available. A post-install script [1] chooses which dependency to install. It seems like a lot of work for the maintainer? But most users don't need to care. It probably helps that the Go SDK builds static binaries. [1] https://github.com/evanw/esbuild/blob/master/lib/npm/node-install.ts https://github.com/evanw/esbuild/blob/master/lib/npm/node-in...

ParetoOptimal 4y ago
> The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. This complicates working on node projects with nix in my experience. Is there a way to tell npm "no, just use my binary"? Best i've found is letting npm download it and then overwriting the npm binary with the nix one in a postinstall script. Why you ask? Npm doesn't always have an aarch64 or arm32 binary. Nix being a source based package manager typically does support it or at least makes it possible by overriding build/configure options.
- skybrian 4y ago
  If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users. Also, I wonder if nix would be a suitable tool for generating npm packages that contain binaries? Maybe this is a way for people to benefit from nix without actually using it.
  - rgoulter 4y ago
    > If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users. The "I have a binary already, just use this one" is in response to the problems NixOS users face dealing with helpful software like this. NixOS doesn't provide shared libraries in the standard locations (for good reasons). Binaries that tools like NPM download will link against shared libraries in the standard location. It's not really a question of "providing the binaries would help", because it's about assumptions of where the shared libraries are.

gavinhoward 4y ago

Disclaimer: I'm working on a build system that will eventually do what Nix does but make it much easier to use. If they do manage to create a system where Nix is hidden, and end users never have to directly touch it, I think this could work and make my work never see the light of day. But I have my doubts that they will be able to do that, and it boils down to one simple reason: declarative is not powerful enough. Don't get me wrong, for 90%, possibly more, of use cases, it's enough. And it is preferable to keep things declarative as long as possible, so much so that my build system will have a way of restricting itself to purely declarative code when possible (and will error otherwise). However, when more power is necessary, it is required; it is not possible, by the definition of Turing-completeness and declarative, to do the same thing with a declarative language that can be done with a Turing-complete language. So when that power is missing, the only option is to work around it. This is why Nix is really just a front for bash. For all of its faults, at least bash is Turing-complete. But this fact means that there will be things that Nix will fail to do on its own. I suspect this means that the abstraction around Nix will always be leaky. Maybe it won't be unacceptably leaky, but I'm not very hopeful. I think Nix would be better served by doing the following: 1. Rewriting the language. This would require an auto-transformer to the new language in order to not throw away the entirety of nixpkgs, but transforming a declarative language to a Turing-complete one is easy. 2. Spend gobs of time on user experience. Make the usual commands short, easy to remember, and easy to use with few options. Make usual things easy and powerful things safe. For example, to make a powerful thing safe, make sure that screwing it up will not screw up their system. 3. But not only should they be safe, they should feel safe, giving users every opportunity to back out without consequences. This is where git goes wrong: it does not feel safe, so users are scared of it. [0] I believe Nix is the same way, even though it is safer than git. 4. Spend gobs of time on documentation. Use Fred Rogers' list of rules for talking with children [1] in each piece of documentation. This will make it easier to avoid the trap of not explaining something the user needs because the writer forgot that they didn't know it. In essence, the documentation should treat new users as Fred Rogers treated children: ignorant, but capable. 5. The documentation also needs to have a different focus. Instead of focusing on how great Nix is, it should focus on helping users get stuff done. Nix enthusiasts should be able to say, "Oh, you want to set up a development environment for your project? Great, go to such-and-such tutorial. It will tell you exactly how to do that even if you don't have Nix installed." This should be done for as many use cases as people have, including less common ones. Some examples: using Nix as a build system, using Nix to install multiple versions of glibc and how to switch between them, using Nix to set up systemd, using Nix to replace a Docker container in production, using Nix to distribute builds, etc. [0]: https://xkcd.com/1597/ https://xkcd.com/1597/ [1]: https://www.mentalfloss.com/article/547536/mr-rogers-rules-for-talking-to-kids https://www.mentalfloss.com/article/547536/mr-rogers-rules-f...

oxff 4y ago

Make the documentation up to the modern standards. If I have to open a single random blog or Github repository to find out what to do and piece it together like a puzzle - it is impossible to adapt at organizational scale. It is also complex enough to require a modern Language Server.

fancyfish 4y ago
This has been my experience also. I finished the Nix Pills, and got some personal Python/Haskell projects built using nixpkgs by following the nixpkgs language-specific documentation, but anything off the beaten path is going to involve lots of blog posts and clicking through source code. For example in the Haskell world there are so many blog posts that go in different directions from the nixpkgs docs, using flakes, haskell.nix, etc. We adopted it in an organization of ~100 engineers, and the only way it’s been possible is having a full-time Nix team writing custom Nix functions specific for our environment and projects. That team also does “Nix help desk” work for one-off questions. Once it works, it does a great job of hermetic builds, easy Docker images, easy to add cross-repo dependencies mixing C++/Python etc. But there are too many rough edges I can’t recommend it in the general case over Dockerfiles, Bazel or language-specific tooling, Cmake, etc. Pick something simpler, ideally whatever is popular for your language.

beermonster 4y ago

Is it Nix or NixOS?

qbasic_forever 4y ago
Both exist. Nix is a functional language for describing how software is built. Nix is also a package manager of sorts that installs and manages software built with its language. NixOS is an operating system that is described entirely by a nix language configuration file that builds a bootable linux-based OS using nix language packages.
grumbel 4y ago
Nix is a package manager & programming language that you can install on any Linux or MacOS to manage software. NixOS is a bootable OS build on top of Nix. Nixpkgs is the default package collection used by both Nix and NixOS.

anderspitman 4y ago

For the first time in about 8 years an Arch update rendered my OS unbootable last week. I'd had graphics issues once or twice but this time it just hung in systemd somewhere. Still don't know what happened. Rolled all packages back about a month and that worked, but I'll need to update eventually. I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom side. Chances are I'll just do a fresh Arch install or maybe try Debian rolling. These days I like to install almost all software and libraries by hand in my home directory. All I really want is a solid system that basically boots fresh then loads my home directory. Maybe I should do a net boot of some sort? Any other suggestions?

iopq 4y ago
I mean, I just add packages to the list and some configuration options. If you only need it as a user it's fairly simple.
Daegalus 4y ago
you can try something like Kinoite or Silverblue from fedora. you can also manage tools with asdf if it makes it easier. I personally run Fedora + Flatpaks + asdf and it covers everything, and is stable, up to date, and has a new release every 6 months. it feels midway between a rolling release and. apoint release
jcynix 4y ago
I just started to experiment with EndeavourOS, a prepackaged version of Arch. Looks nice so far. https://endeavouros.com/about-us/ https://endeavouros.com/about-us/
sph 4y ago
Eh, I'd just use Silverblue. You get the benefits of immutability, without having to learn a new language and weird tools to manage your workstation. I ain't got time for any of that.
Sugimot0 4y ago
Just a heads up, the issue was likely grub, grub had a breaking change for certain EFI devices. You can check arch news etc for more info. I had to chroot and fix my laptop the other day cause it was stuck boot looping after I upgraded.

ontouchstart 4y ago

I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago. I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate Systems. Don’t get distracted by language features and syntactic sugars. If it works, people will learn.

JustLurking2022 4y ago
I've worked with large scale monorepos in FAANG - as a rule, they all suck. Eventually you always end up in this place where you have to understand, and be prepared to debug the entire universe just to build hello world.
- ontouchstart 4y ago
  Totally agree. For complicated system, this essential complexity won't go away no matter how you make the UX "friendly". But good tooling will help users grow to understand the challenge of the problems as well as to appreciate the power of the solution. For people who are really interested in the solution, they will eventually dive deeper: https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
- deleted 4y ago
  [deleted]

lykahb 4y ago

The name Nix is used for the language, package system, and sometimes the whole ecosystem. There is a recent post that tells the difference https://www.haskellforall.com/2022/08/stop-calling-everything-nix.html https://www.haskellforall.com/2022/08/stop-calling-everythin... Knowing functional programming helps but Nix still is a hard language to learn. I have a lot of Haskell experience but the Nix language was very confusing for me. At first I couldn't even tell a variable name from a keyword (it is a convention to call variables "self" and "super" in some contexts). The Nix language has been created for research in build systems and has evolved over a long time, so it has accumulated quite a lot of idiosyncrasies and cruft. I hope that a simpler typed language like https://github.com/tweag/nickel https://github.com/tweag/nickel replaces it.

kaba0 4y ago
I believe blaming the language is misguided. The problem is that nixpkgs’ constructs are not well documented, or not yet stable. It would be a problem in any language (you can’t expect someone to feel familiar in a new codebase, and nixpkgs is essentially that).
- lykahb 4y ago
  Yeah, the conventions of nixpkgs are a much bigger obstacle than the language syntax. The language lacks static typing. Also, it is a common convention to create attribute sets crafted for logic that has indirect hard-to-follow links to module where the set is defined. This makes it hard to develop tooling like linters or LSP implementations.

AprilArcus 4y ago

Just let me a pin a single package to a version number, for the love of God.

kaba0 4y ago
What does that version mean? What compile flags was it compiled with, which compiler, etc?
grumbel 4y ago
You can do that with something like this: pkgs.yourpackage.overrideAttrs { prev: { src = fetchurl { url = "..."; sha256 = "..."; }; }} Bit annoying that you have to specific the full URL instead of just the 'version' number, but it'll work. With flakes you can just add a 'ref' or 'rev' to the URL: nix run "github:juser/software?ref=v0.4.1" If you want to override a package dependency across 'override'.

dd_ 4y ago

As someone who has been using NixOS for a couple of years now, I really want to say how appreciative I am of everybody for making noticeable improvements to the system on a somewhat regular basis. The nix command keeps on adding great new features like flake templates and bundling as well as just being more user friendly (error messages, actionable hints, etc.) Additionally, tools like nix-ld [1] make nix more usable than ever with software from external sources. Things just keep on getting better for NixOS users! Despite the reputation, I feel that NixOS or some derivative of it has the power to become the best distribution for non-technical users in the long run. What NixOS has done is effectively built an interface to every component of a modern Linux system, all that needs to be built is a user application to take advantage of it. Of course, there still needs be some improvements in Nix itself for it to blossom into its final form, but I really see a path to greatness here. I have often thought about creating a simple unified Win2K-esq or BeOS-like X11 WM/DE specifically for NixOS but unfortunately I lack the time/motivation. [1] https://github.com/Mic92/nix-ld https://github.com/Mic92/nix-ld

colordrops 4y ago
Yes, I could imagine a very locked down opinionated distro built on top of Nix that completely abstracts away all of it and makes it work somewhat like Ubuntu with some prepared nix templates/metaprogramming to automatically generate config. Over time more of the Nix functionality could be exposed through UI or more friendly cli tools as best practices and nix itself evolve, allowing the distro to remain friendly to non-technical users while opening up it's true powers to them. It wouldn't be able to handle arbitrary manual changes to config at the beginning, so either there would always be a protected generated config region of the whole config and the distro would remain relatively standardized, or an alternative evolution would be a low-code user friendly UI that could map to any possible nix config.