Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

brioche.dev

Post reply on HN
Print view View original

31–40 of 90 posts

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

#31

Post by kylewlacy »

Aerbil313 wrote: post #13
zamalek wrote: post #11

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…

I suggest the post author and you look into nu as the package build language. It's uniquely suited for this task, being a cross-platform shell[1] with real programming language features, data types, and using built-in uutils instead of relying on platform-dependent coreutils. It also limits mutability[2], favoring a more functional than imperative approach, which would at least theoretically help with reproducibility…

Nushell has definitely been on my radar for a while! but I missed DetSys was playing around with it, I'll have to give that a look

One neat thing about Brioche is that Bash isn't really baked into it the same way as the Nix ecosystem. In a lot of the docs and examples, I used the `std.runBash` Brioche function for running scripts, but that's a fairly simple 11-line function[^1]. I wanted to make it just as easy to add `runZsh`, `runFish`, `runNushell`, etc. functions that work just as well as Bash (and they could either be put in the std library or in their own packages). So hopefully, there will be a Brioche `runNushell` function in the near future :)

[^1]: https://github.com/brioche-dev/brioche-packages/blob/9fd5109...

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

#32

Post by mmgutz »

leoh wrote: post #22
andrewla wrote: post #7

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…

flox is the best thing I know of for articulating binary dependencies (language runtimes, etc.), which is probably the sweet spot for nix anyways at the moment (i.e. as opposed to trying to build everything "With the One [Tool] to [Replace] Them All"). flox uses nix for its backend, but has a simple TOML syntax and is properly humble about what it can do -- but killer at it -- as opposed to promising the world. https…

There's also [devbox](https://github.com/jetify-com/devbox).

Tried a lot of them, and after a while I found the nix the package manager on non NixOS requires too many workarounds. Things don't just work. For example, installing alacritty requires an OpenGL wrapper. Neovim can't find libraries to build some plugins. Basically, anything GUI had issues.

In the end, `cargo install`, `go install` and download a release archive from github are simpler to script for most of the tools I use.

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

#34

Post by whateveracct »

charlotte-fyi wrote: post #5

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!

ever use nix repl? i found my complaints about grokkability disappeared once i realized i could easily introspect my build (and all my dependencies' builds) at any level.

that + learning the like 5 or so idioms that pervade nixpkgs and you can use Nix quite successfully imo.

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

#35

Post by hamandcheese »

likium wrote: post #16
andrewla wrote: post #7

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…

Starlark is widely used by Bazel and Buck. That would fulfill similar properties and build system folks have one fewer thing to learn.

Yes, and Bazel makes some very serious trade-offs in order to make starlark work. Notably, dependencies are referenced as stringly labels as a poor substitute for lazy evaluation (starlark itself has strict evaluation semantics).

This in turn requires additional tooling to catch errors early, and also means that a starlark-repl for Bazel will never really be all that useful, since the build graph doesn't exist in starlark alone.

In my experience, this makes Bazel a significantly harder build system to truly grok, tho perhaps easier to use it without understanding it.

Contrast with nix, where the entire build graph exists as a nix expression. In my experience, you can gain a surprisingly deep understanding of nix armed only with knowledge of nix-the-language (and without knowing any implementation details of nix-the-binary-that-builds-derivations).

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

#36

Post by hamandcheese »

__MatrixMan__ wrote: post #15

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, bu…

I think the lack of true laziness will be a big performance problem for a large build graph.

On the other hand the monolithic nature of the nixpkgs package set is one of the authors gripes with nix, so performance at that scale may be a non-goal.

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

#37

Post by kylewlacy »

hamandcheese wrote: post #36
__MatrixMan__ wrote: post #15

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, bu…

I think the lack of true laziness will be a big performance problem for a large build graph. On the other hand the monolithic nature of the nixpkgs package set is one of the authors gripes with nix, so performance at that scale may be a non-goal.

I'd definitely like to have good performance even for large build graphs! I'm hoping the laziness exists "where it counts". To walk through an example, if you build your backend, and your backend calls the function `postgres()`, and that calls `openssl()`, and THAT calls `gcc()`, etc., etc., each function is basically building an object to represent its chunk of the build graph (each function returns a "recipe"). Nothing gets built until that object gets returned from the top-level function and the runtime does something with it

In other words, the eager part is basically constructing the build graph. Maybe I'm wrong but I don't that this would necessarily be slower than the lazy version. In practice the most complex build graph I've made is basically the full chain of Linux From Scratch builds (that's the basis for my toolchain currently), and I think that takes about 400-500ms to evaluate. It's about 160 build steps, so it's not _simple_ but I know build graphs can also get a lot more complex, so I'll just have to keep an eye on performance as I start to get into more and more complex builds

Maybe I'm missing something but intuitively I'd expect this approach to be fairly efficient-- as long as build scripts only call these functions when they're used as part of the build graph

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

#38

Post by hamandcheese »

kylewlacy wrote: post #37
hamandcheese wrote: post #36

Earlier quoted context omitted.

I think the lack of true laziness will be a big performance problem for a large build graph. On the other hand the monolithic nature of the nixpkgs package set is one of the authors gripes with nix, so performance at that scale may be a non-goal.

I'd definitely like to have good performance even for large build graphs! I'm hoping the laziness exists "where it counts". To walk through an example, if you build your backend, and your backend calls the function `postgres()`, and that calls `openssl()`, and THAT calls `gcc()`, etc., etc., each function is basically building an object to represent its chunk of the build graph (each function returns a "recipe"). Not…

I think it really depends on your definition of "large". I don't think strict eval + full build graph can scale to something the size of nixpkgs, for example.

I mentioned in another comment that this is why Bazel uses simple strings to form dependencies on other targets. That way Bazel can manage the laziness and only evaluate what is needed without needing to use or invent a language with lazy evaluation.

But that is also the big downside (in my opinion) - the full build graph necessarily can't exist purely in starlark (at least for Google-scale projects) which increases complexity of the tool overall.

Edit: I'd like to add, though, that I think it's perfectly fine to not scale to Google scale or nixpkgs scale! Many many projects could still benefit from a great build tool.

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

#39

Post by zarathustreal »

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.

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

#40

Post by chubot »

zamalek wrote: post #11

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…

I have subsequently decided that shell scripts (or anything you can shebang) are good enough, i.e. pkgbuild inspiration.

If you run out of steam with shell, keep Hay in mind -- which is part of Oils.

It upgrades shell with declarative data, like YAML but not YAML syntax :)

https://www.oilshell.org/release/0.22.0/doc/hay.html

Discussion - https://lobste.rs/s/phqsxk/hay_ain_t_yaml_custom_languages_f...

It's not set in stone yet -- I'm planning an overhaul based on some feedback, so I welcome any more (e.g. on Github or Zulip)

Post reply on HN