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.
Very exciting. The ideas behind Nix are so good and everything else so bad. It seems like a lot of people are trying to solve this by building abstractions on top of Nix, but I'm really skeptical that is the solution. As crazy as a full rewrite is, I hope someone succeeds!
I'm really happy to see more work on package managers in this space. I used Nix for a little bit, but I shared the frustration expressed by other commenters on the language itself. I have found my zen on GNU Guix, but more options are better :)
Beat me to it! It's my dream to write a Nix replacement in a more approachable language. I can't state enough how the choice of a bespoke DSL that doesn't immediately make sense to most developers keeps Nix/Nixos community from growing. And Nix is 18 years old now, it's long overdue for a rewrite[1]. Don't implement channels to start with. Focus on full reproducibility. (...getting into sci-fi territory...) Build in QEMU and KVM virtualization to be able to build and run most pieces of software ever published. No, Docker is a horribly leaky abstraction. Run a torrent network by default as cache.nixos.org equivalent, because you can't keep up with the demand with centralized solutions, even nixpkgs gave up on it despite their free credits on AWS.
1: I believe all software without exception needs a full rewrite at least every 10 years.
Looks awesome! Congrats on the release. I would be curious to hear your thoughts on how this compares to garn [1], a typescript front end to the existing nixpkgs ecosystem.
I'm very excited by all the attempts to replace Nix, but I don't think I'll be exploring this much deeper.
In my opinion the issue with Nix is that the data model is not crisply defined -- it's there, but hidden under a lot of goop that is the Nix language itself and the various assumptions and baggage that goes with it.
What I want is a primarily declarative syntax supporting a rich set of data structures, ideally a non-Turing set of primitives, with a much more intuitive way of gluing things together. So basically bash (or even sh) with a well-defined way of transmitting environment variables and setting up the environment.
The idea of importing a language that has broader support (typescript) as an alternative to the Nix language seems appealing at first, but typescript is such a high-dependency system that it's hard to get excited about it.
Some of the oddities of the nix language are pretty useful for its domain. Recursive attribute sets, for instance, save a lot of headaches if you're trying to have only a single source of truth. Do you feel like these translate to typescript nicely?
As somebody who knows nix but doesn't know typescript, I found myself looking for a rosetta stone page where I could look at two chunks of code that do the same thing, but in separate languages. This would let me use the familiar language to scrutinize the other.
I wouldn't normally ask for such a thing, but if you're putting "Nix-like" in the title then maybe it might be worth adding a comparison page to the docs.
I actually haven't tried Nix (or other nix-alternatives) yet. I've seen a lot of complaints about the language, but a lot of praise and love of the idea. I though Guix was the "main" competitor to nix, using a more mainstream language (Scheme). Is that still the case? How would Brioche compare against Guix if you are OK with both Scheme and Typescript as languages?
I'm also exploring a post-Nix package manager, wip: https://github.com/porkg/porkg
My mantra has been to avoid "getting bored" and inventing DSLs for the longest time. I initially sought to use Nickel-lang, but it was missing some features that would make it an ideal candidate for this. I started writing my own (you may find this in the history) before realizing "WTF are you doing writing another shitty DSL?" I have subsequently decided that shell scripts (or anything you can shebang) are good enough, i.e. pkgbuild inspiration.
I also plan to avoid making a derivation the source of reproducibility. Instead, a lockfile will offer that. This should alleviate the issue whereby updating the like of glibc cascades into an entire rebuild.
Any *OS and home-manager would need to bring in a configuration language. I think Cue really makes the most sense, but that's still a long way off.
Nice to see you used JS instead of yet another DSL :)
Wow, congrats for the release!!!
But, can we revisit the name? “Brioche” sounds cool but (at least for me) it’s so awkward to type on the terminal and pronounce
I am not writing typescript -- heaven forbid -- so I can manage cargo, so I can write Rust.
Dropping the snark, though -- most times I have seen folks attempt to fold other build systems into some polyglot common one, it seems to create a lot of problems -- for at the end of the day, build tools (whether npm, cargo, gradle, docker, etc.) each have their issues. When these issues arise, they require understanding the original build tool. Bazel, for example, is a "polyglot" system which many try to use to manage npm. In my experience, when folks use bazel but have never used npm directly, they often get lost, because they now have to deal with two abstractions (bazel, npm) simultaneously neither have a way for bazel to do the thing they need, nor an understanding of how to get bazel to do that thing (nor npm itself to do the thing), also because they have never worked with npm directly.
Same goes for cargo, incidentally. Switching over to that build tool -- like any major build tool, it has an insane amount of well-honed documentation and thousands of answered questions online (not to mention LLMs trained somewhat well on it). Users when they need to do something with brioche or have an issue with it will not necessarily have the benefit of the massive collaborative support available for cargo.
Incidentally, I don't think that nix is free of this problem, though it does attempt to manage these issues -- sometimes reasonably successfully -- by virtue of keeping interfaces to other build tools in simple, direct ways.
Even then, however, the best way I have seen nix used is as a system for declaring all binary dependencies or other dependencies that are either not manageable or especially competently managed by other build tools -- which nix allows for in a virtual environment by shipping a shell.nix or flake.
In other words -- bringing in the right version of java, gradle, node, etc. But then just directing users to the specific, native build tools that often have a massive number of contributors.
The closest thing to a tool that does this (guides developers to other build tools) is flox, which uses TOML, but uses nix for its backend via C API. I haven't had a chance to use it much yet, but it looks very promising https://flox.dev.
===
Okay, all this rambling aside -- building a tool like this for yourself or a small team, especially when you have the time to do it, it works well, and you're having fun... well, there's an insane amount to be said for that; and it will doubtlessly lead you to learning a ton about other build tools and likely offer you deep insights that are only possible when attempting to build something like brioche. So, on that count, major kudos to you.
Can't we have something Python based, since it is already the lingua franca and seems to be the language that people are least frustrated about?
Reading the comments makes me think I'm turning into my dad. He was a simple man in terms of education and career. He was a fire man on a stream train in 1950, a farmer, barman, handyman. Out in the sticks, he was everyone's go-to guy when a vet couldn't be found, because he kept a "livestock first aid kit" including penicillin & syringes. He talked to vets and read books and knew about the most common ailments and how to treat them. He serviced his own car and tractor, including stripping the tractor engine down in his yard without proper tools, and getting cylinders bored and pistons sleeved, and putting it back together. He ran electric cable in farm building and sheds (after chatting to an electrician) and he did a ton of building work around the house. But at a certain age, maybe around 50, all new technology was out. Electricity was fine but electronics were out. Mechanical problems were fine because you could look straight at a thing and figure out how it clicked together, but once it had a microcontroller and a panel that abstracted away the actual working of the machine it just became some weird arbitrary "thing" that blocked his view of the machine. I'm sure if he was in his 20s when this stuff appeared he'd be all over it, but he was born in 1926, so I think the mighty micro was too late for him. He flatly refused to use the VCR, alarm systems, any type of computer. Show him a rubis cube, he's interested. Show him a microwave oven with more than 5 buttons and he'll make a sandwich instead.
This is me with nix. I'm ok with all the stuff that's emerged in my field (infra/sysadmin) since the 90s. But nix makes me instantly glaze over. Several times I tried, but it's like my brain unplugs itself. I'm sure it does some wonderful stuff at an extremely high price that I'm not willing to pay.
Nix has a huge mindshare, which I don't think you can win back if Nix keeps fixing the core issues mentored in these comments. Best of luck with this, though.
I’ve always wondered why no one ports FreeBSDs pkg/ports package management system. From all the operating systems I’ve used it’s the clear leader.
I’ve generally found the most interesting things are the ones that don’t feel intuitive at first. Familiarity bias can really hold you back. The language semantics of Nix are basically Haskell’s which.. is probably the One True Way to write correct code if we’re honest with ourselves.
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.