Live data from Hacker News

Nix at work: FlakeHub Cache and private flakes

determinate.systems

11–20 of 32 posts

Re: Nix at work: FlakeHub Cache and private flakes

#11
I appreciate someone from the project commenting here. I left Nix because it just has too many warts, and unfortunately, they've only increased over time, which is the opposite of what I expected.

- I'd update Nixpkgs, and my build would stop working. The logging was awful, so fixing it took hours.

- The mono repo sounds nice, but selective updates are almost impossible.

- Building our Go project in a Nix package was nearly impossible with private GitHub repos, so we moved on.

- Bash scripts never work because binaries are never where they should be in Linux.

I could go on, but my experience with Nix and NixOS left me with significant scars. I’m hopeful that someone will eventually create a more user-friendly deterministic OS.

Re: Nix at work: FlakeHub Cache and private flakes

#12
post #11

I appreciate someone from the project commenting here. I left Nix because it just has too many warts, and unfortunately, they've only increased over time, which is the opposite of what I expected. - I'd update Nixpkgs, and my build would stop working. The logging was awful, so fixing it took hours. - The mono repo sounds nice, but selective updates are almost impossible. - Building our Go project in a Nix package was…

> - Building our Go project in a Nix package was nearly impossible with private GitHub repos, so we moved on.

Yes. This is a nightmare, and is the literal step-one problem FlakeHub is designed to solve.

Regarding the monorepo causing big-bang updates that broke all your stuff: continued, strong, agreement. I think as nixpkgs continues to grow, and usage grows, we'll see a wider adoption of flakes from a pure "how do we all work together?" perspective. That's the flip side of FlakeHub's initial concept.

Re: Nix at work: FlakeHub Cache and private flakes

#13
post #12
post #11

I appreciate someone from the project commenting here. I left Nix because it just has too many warts, and unfortunately, they've only increased over time, which is the opposite of what I expected. - I'd update Nixpkgs, and my build would stop working. The logging was awful, so fixing it took hours. - The mono repo sounds nice, but selective updates are almost impossible. - Building our Go project in a Nix package was…

> - Building our Go project in a Nix package was nearly impossible with private GitHub repos, so we moved on. Yes. This is a nightmare, and is the literal step-one problem FlakeHub is designed to solve. Regarding the monorepo causing big-bang updates that broke all your stuff: continued, strong, agreement. I think as nixpkgs continues to grow, and usage grows, we'll see a wider adoption of flakes from a pure "how do…

Please keep at it! Doing what GitHub did for Git is a real opportunity I think for Nix. We'll be keeping an eye on Determinate's work...

Re: Nix at work: FlakeHub Cache and private flakes

#14
post #4

Earlier quoted context omitted.

There is a lot of turbulance in the project, but I think a lot of that is a natural result of twenty years of history meeting standout commercial success. Our approach here is to continue our pattern of improving Nix and sending patches upstream. We'll also continue improving the ecosystem around Nix, most of that being open source, and only a couple specific projects being proprietary. Regarding the stability of the…

As someone who just went back to Arch after using NixOS as my daily driver for more than six months, what's in dire need of improvement is the documentation, the rest of the ecosystem was all right.

I'm still driving nixos, but for me, the stacktraces are the hard part when discerning where and why things have gone wrong

Re: Nix at work: FlakeHub Cache and private flakes

#15

Given the extensive infrastructure you and others are building around flakes in the Nix ecosystem, despite flakes still being experimental, what does the roadmap look like for your efforts, and more broadly for officially establishing flakes??

The roadmap is closed-source solutions as described here: https://discourse.nixos.org/t/introducing-flakehub/32044/3

Re: Nix at work: FlakeHub Cache and private flakes

#16
post #3

Has the situation between you guys and the Nix community cooled down yet? I have honestly avoided NixOS for quite a while because the situation seemed "unstable". I don't particularly care for the complaints brought about by the open letter, I do however worry if a distribution/community is imploding.

I think it's worth jumping in. Fifteen years ago, it wasn't clear whether Git, Mercurial, or Bazaar would win, but it was evident that something fundamental had forever changed in revision control systems.

Nix feels similar, but for build systems, package management, and configuration management all at once.

Re: Nix at work: FlakeHub Cache and private flakes

#17

Earlier quoted context omitted.

As someone who just went back to Arch after using NixOS as my daily driver for more than six months, what's in dire need of improvement is the documentation, the rest of the ecosystem was all right.

I'm still driving nixos, but for me, the stacktraces are the hard part when discerning where and why things have gone wrong

Ugh. I feel you. I think one thing that makes this hard is how big and intertwined Nixpkgs and NixOS is. All the modules are loaded all the time, and it can make the displayed errors propagate out to somewhere intractably far away from where the error actually is. There's a ton of work still being done in Nix to make that better, and I'm hopeful for an easier future :').

Re: Nix at work: FlakeHub Cache and private flakes

#18
post #10

Can someone do a ELI5 of Nix and flakes for me? I've looked at the docs numerous times and bounced back each time after I failed to understand the USP of Nix...I just don't know what's the main use case(s).

I've been meaning to write something pithy on this and this is a great spur to action. Basically Nix is something you use to build software reproducibly, that is, where you can take the same inputs and get the exact same bytes on disk every time you build it. The "software" here could be something simple-ish like a CLI tool or a UNIX utility, and it could be as complex as an entire functioning Linux system, and it could be something that you usually build using other tools, like Docker or Podman containers. Nix can do all of this. I'd say that the things people most often use Nix for are:

1. Project-specific development environments. You want everyone on your team to have the exact same version of Python, jq, Terraform, Cargo, and Bun in a specific project? Nix can do that. 2. Home environments. You want to replace your dotfiles and Homebrew and apt-get with something declarative that you have an actual language for? Nix can do that.

So yeah, development environments, home environments, whole Linux systems, OCI containers, standard packages (like CLI tools), things like VS Code extension, Neovim plugins... all of this stuff can be built using Nix. Pretty powerful stuff.

Re: Nix at work: FlakeHub Cache and private flakes

#19
post #13
post #12

Earlier quoted context omitted.

> - Building our Go project in a Nix package was nearly impossible with private GitHub repos, so we moved on. Yes. This is a nightmare, and is the literal step-one problem FlakeHub is designed to solve. Regarding the monorepo causing big-bang updates that broke all your stuff: continued, strong, agreement. I think as nixpkgs continues to grow, and usage grows, we'll see a wider adoption of flakes from a pure "how do…

Please keep at it! Doing what GitHub did for Git is a real opportunity I think for Nix. We'll be keeping an eye on Determinate's work...

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.

Re: Nix at work: FlakeHub Cache and private flakes

#20
post #15

Given the extensive infrastructure you and others are building around flakes in the Nix ecosystem, despite flakes still being experimental, what does the roadmap look like for your efforts, and more broadly for officially establishing flakes??

The roadmap is closed-source solutions as described here: https://discourse.nixos.org/t/introducing-flakehub/32044/3

lol. We have two closed source projects that are meaningful in any way: FlakeHub, and determinate-nixd.

Everything else we have is, and all of our improvements to Nix are, open source and permissively licensed. That includes Determinate Nix Installer and zero-to-nix, both of which are permissively licensed with the hope and intention of the upstream project adopting or integrating the material as they saw fit.

Post reply on HN