Show HN: Brioche – A new Nix-like package manager

Flakes definitely help with the giant megarepo annoyances of NixOS, though they're still a little irritating. If you are writing in a languages that doesn't hasn't had its packages directly integrated into the build system (like Python's has), it can be really irritating to do anything with them, since the `nix build` command disables network access and you therefore cannot use regular package manager.

I'm doing a project in Julia, and I'm using Nix Flakes to do it, but it's been immensely annoying to actually get that working [1]. As a result, I've had avoid using the `nix build` command entirely (though the flakes are still useful for the `nix develop` command).

All that said, do you plan on having Brioche work with reproducible builds, and if so do you have a plan to make what I mentioned a bit less irritating?

[1] I know Julia2Nix exists, and I have never managed to actually get that working on any platform.

Congrats on the release! I love the focus on devex w/ typescript and autocomplete. That's probably one of my biggest pain points with Nix -- writing any non-trivial package always requires a ripgrep adventure through nixpkgs. Finding the right poorly documented and poorly discoverable derivation attributes is always such a chore.

What are your plans for cross-compilation or heavy package customization? One of nixpkgs coolest party tricks imo is that you can just change the stdenv and get a musl static binary or cross-compiled binary.

This was one of my bigger pain points with Nix as well: there was a lot of "reinventing the world" just to avoid network access. With Brioche, I stuck with disabling network access by default, but there's an escape hatch to specifically opt-in to networking (by calling `.unsafe({ networking: true })` on a process recipe). My thoughts are that Cargo, NPM, Poetry, etc. have all done a great job building amazing tooling to download and verify resources from the network against a lockfile, and I wanted to be able to leverage as much of that as possible. So, for example, `npm clean-install` will give you more-or-less the same guarantees that Nix does, so my thought was as long as it's encapsulated properly, I'd rather lean on existing tooling (that's also why I used the term "unsafe", you need to make sure you only access the network with tools that do sufficient verification!)

I've generally stayed away from using the term "reproducible build" when talking about Brioche, because I don't feel like it fits the reproducible-builds.org definition (though I don't think Nix does either). But, if a build is cached locally or in the registry, then you're guaranteed to get the same result, since it'll just re-use the cache

The sandboxing also gives pretty strong guarantees around hermetic builds[1]. So I think you could do reproducible builds _within_ Brioche (and I'd like to add tools to make this even easier), but I'd say Brioche itself doesn't give you reproducible builds out of the box

[1]: https://bazel.build/basics/hermeticity

Agreed. NixOS is a marvel of engineering to me, and kind of hard to go back from once you get used to it. Automatic snapshotting on every configuration change, the entire system state being configurable through text files and therefore never being ambiguous, being able to temporarily install stuff without it polluting your path for forever by using nix-shells, clearly being able to see and define stuff like boot parameters and kernel modules are just insanely wonderful things, all while still using (I think) a vanilla kernel and really no runtime overhead, allowing you to make an insanely lean system without ever being unsure if you're missing something or having to worry about extra crap that you installed by accident lingering forever. In my mind about as close to an "objectively better" way to handle an OS (at least for people who are technical) as one can ask for. I have no desire to go back to any other distro for my server.

But the Nix language itself is really quite annoying. I mean, I've more or less gotten used to its annoyances, and I do think that some of the DSLs it has are excellent (I really like the Nginx and systemd configuration stuff, for example), and a lot of the configs are just `services.myservice.enable = true` which is fine, but a lot of the time I'm kind of confused about what syntax is allowed and how loops work and the like. It's not horrible or anything, just a bit annoying because I'll occasionally have to do a nixos-rebuild like three or four times because I messed up some subtle syntax, and it's especially annoying if I have to go dig at the root Nix package to find out what I did wrong [1].

I think decentralizing stuff in the form of flakes might be able to help with this, if for no other reason the area in which you'd be forced to look for configuration stuff could be reduced, but I do think NixOS would benefit from some rearchitecture.

[1] Which happened yesterday with an ethernet card configuration: https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modu...

> What are your plans for cross-compilation or heavy package customization? One of nixpkgs coolest party tricks imo is that you can just change the stdenv and get a musl static binary or cross-compiled binary.

So in general, I don't think I'm going to have anything quite as powerful as Nix's overrides. But I'm hoping most of the use-cases for it will be covered by some simpler options:

- Since build definitions are functions, package authors can just take arguments for the things they want downstream users to be able to customize (e.g. `configure` flags, optional features and plugins, etc.)

- I haven't built it yet, but I think adding support for dependency overrides would be fairly easy, a la Cargo. Basically, you'd just fork or clone the package you want to tweak, make your tweaks, then set an "overrides" option to use it instead. I know that's not a super satisfying answer, but that should help cover a lot of use cases

- For toolchains specifically, I have an idea in mind for this as well (also not implemented at all). At a high level, the idea is that packages could use "dynamic bindings", which you can then override for downstream recipes (this would require some new runtime features in Brioche itself). The toolchain itself would effectively be a dynamic binding, letting you pick a different recipe (so you could swap glibc for musl, or gcc for clang, etc). Cross-compilation would also be built on this same feature