I want to install binaries with cargo instead of doing the same build again and again. Similar to https://cachix.org
I don't honestly know why that isn't the case yet, perhaps storing binaries takes too much storage that Mozilla doesn't have money for. Or perhaps it can't do guarantees like the ones Nix gives to allow binaries being shared of builds.
This is the main reason that makes interfacing with Rust as a plain user a pain.
Is it expensive to maintain all the binaries for all of Hackage?
What is missing is cargo support for native libraries.
(import <nixpkgs> {}).your-favorite-projectIt's one of those tools that are technically miles ahead of their competitors but struggle to gain traction because of beginners facing little cuts and bruises in using them.
That's why I'm interested in the Nix Modules proposal to be presented in the conference that aims to bring better usability to the language with types and docs.
Also the updated website is a lot easier to navigate now and explains the use cases of nix quite well
It's been the steepest learning curve, but yeilded the biggest dividends so far.
The other day I needed to install some software from a specific 3 year old branch. Copying the default.nix for the up to date version and changing a few of the options got it up and running with minimal fuss.
There are certainly some rough edges around usability, but the fundamental value prop is immense.
Also just using nix as a secondary package manager on mac or some other Linux distro is great, I'd expect shell.nix to start showing up in an increasing amount of OSS projects. It showed up in hashicorp's latest project
A more expansive list of my issues with nix (with some curse words :p): https://gist.github.com/est31/005f17628d55fda27b401d3c994233...
> No concept of source packages. There is only a binary cache (hydra) and the derivations in nixpkgs.
NixOS _Only_ has a concept of source packages. The cache is a (sound) optimisation om top of it. just disable the binary cache and you can build all packages from source.
The package definition describes how to fetch the source code from a source (like a Git repo or a hosted archive) and build it. The built result only contains what is necessary at runtime.
A sizeable amount of packages don't even fetch source code but a prebuilt binary which is then fixed up to work with Nix.
There is a source cache, but it is optional.
As an example, check out ripgrep [1]. It uses `fetchFromGithub` to retrieve the code.
[1] https://github.com/NixOS/nixpkgs/blob/3bb54189b0c8132752fff3...
I'll be speaking how about how to get Nix to become mainstream.
Anyways, the widget at https://2020.nixcon.org/#program localizes to your timezone (but also shows weird dates sometimes).
Times from the cfp subdomain are all in UTC.
YouTube link at https://www.youtube.com/watch?v=7sQa04olUA0
> nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8"
I thought this was pretty cool, but unfortunately, this doesn't work on macOS...
nix-shell --packages mpv --run "mpv https://dash.nixcon.net/dash/master.m3u8"I was just sad that I couldn't use the cool Nix magic to view the stream.
A functional language, a package manager and an operating system.
I switched all my desktops and laptops to NixOS at the beginning of the year, and I'm starting to use introduce it at multiple companies for data science / ML work environments with full reproducibility and Kubernetes bare metal deployments.
Main benefits:
* pure build system
* extremely easy way to set up and switch between custom environments with their own sets of dependencies (nix-env, nix-shell)
* nix (the package manager) is cross-platform and works on MacOS and other Linux distros (although that's not always smooth sailing...)
* Ephemeral environments that are quickly set up and torn down, like the `nix-shell --packages vlc --run "vlc https://dash.nixcon.net/dash/master.m3u8"`
* (mostly) fully reproducible OS and user environments
* patching and/or locally building dependencies without ending up with a messy system
I can now finally get a (almost) 100% reproducible user environment including hardware configuration (kernel modules, disks, ...), installed packages, configurations, ...
home-manager [1] even enables declarative configuration of things like VS Code/Vim/Firefox plugins, and provides statically typed configuration options for many applications. The package repo is also very comprehensive.
For manually managed servers that aren't just bootstrapped from VM/cloud images the benefits are also wonderful.
It's definitely not all smooth sailing though:
* There is documentation, but it's spread across a lot of pages, disorganized and sometimes quite outdated or incomplete. I often have to read the source code - which is also mostly undocumented.
* Running unpackaged software: you can't just download binary releases and run them, unless they are fully statically linked (like most Go binaries). Instead you either have to whip up a package definition, or manually try to get the binary working (eg with patchelf)
* The language is somewhat quirky. As often the case with such niche languages, documentation and tooling are very subpar and debugging is not exactly a joy. I wish Nix was built on a more common language with good tooling around it. I bet it would be quite a bit more popular, due to the lower barrier of entry. You get used to it though if you are willing to put in some effort.
* Package ecosystem: the package repo is really comprehensive, but maintainership for some less popular ones is not up to Arch + AUR levels. Also the auditing for a lot of the packages is very limited. For any security critical environments or server deployments I would definitely limit myself to a hand full of core packages and/or be prepared for manual auditing. I wish the repo was split up more like Arch into core and community, with different guarantees for auditing and maintenance. (the Flakes effort will hopefully help here quite a bit)
All in all Nix is great though, and it's impressive how stable and featureful the ecosystem has become, despite being somewhat of a niche "product".