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

81–90 of 90 posts

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

#81

Post by nine_k »

from-nibly wrote: post #78
nine_k wrote: post #56

Earlier quoted context omitted.

Go find a place where the struct value is clearly defined. It may seem that any definition is final, but none is. Since the last definition of a struct field overwrites a previous one, the order in which e.g. files are interpreted matters. It's like writing a config by using Python dicts, with the added complication that creation of a new one and updating of an existing one are indistinguishable. This may be okay in…

No it cant overwrite values. It has to agree or it will throw an error. You can have wider types being overridden by more closed types. e.g. string => "this literal". But you cant have two disagreeing values. I use this to create kubernetes manifests at work, at a reasonably large scale. The inability to join multiple files without fear of collision is specifically one of the best features.

Hmm, looks better this way!

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

#82

Post by Sadzeih »

from-nibly wrote: post #78
nine_k wrote: post #56

Earlier quoted context omitted.

Go find a place where the struct value is clearly defined. It may seem that any definition is final, but none is. Since the last definition of a struct field overwrites a previous one, the order in which e.g. files are interpreted matters. It's like writing a config by using Python dicts, with the added complication that creation of a new one and updating of an existing one are indistinguishable. This may be okay in…

No it cant overwrite values. It has to agree or it will throw an error. You can have wider types being overridden by more closed types. e.g. string => "this literal". But you cant have two disagreeing values. I use this to create kubernetes manifests at work, at a reasonably large scale. The inability to join multiple files without fear of collision is specifically one of the best features.

As someone who works with Kubernetes every day and has been curious about CUE for some time, can you describe a bit how you're using it to create manifests? Did it replace helm for you? Or is it to create CRDs?

Edit: I'm struggling to see where it fits in the whole k8s ecosystem.

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

#83

Post by hamandcheese »

aseipp wrote: post #53
hamandcheese wrote: post #38

Earlier quoted context omitted.

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 i…

Honestly, I think the "stringly-typed targets" thing isn't too bad, having used Buck2 quite a bit, and being a Nix user for 10+ years. If anything, it's a small price to pay for some of the other smart things you get in return, like the far more fine-grained action graph and the tooling around BUILD files like querying. One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to m…

> One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to meaningfully evaluate or even parse correctly, so you can still build other subsets of the tree even when things are broken; at ridiculous-scale it's nearly impossible to guarantee that, and it's something Nix does worse IMO since evaluation of the full nixpkgs tree is slow as hell in my experience but a requirement because a single eval error in the tree stops you dead in your tracks.

I think you get more or less the same property with Nix. You can have all kinds of errors, even certain syntax errors in the same file, but if they are unneeded for the current evaluation, they won't cause any problems.

As for language familiarity/approachability - this will always be a matter of opinion, but I personally don't think it makes sense to optimize for the casual contributor. Plenty of people know python, but I never see casuals making anything besides trivial changes to bazel build files. I don't think they gain anything by familiarity with python, they could very well copy paste nix or any other language. And if they get in to trouble, they will call in the experts.

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

#84

Post by davidalayachew »

zarathustreal wrote: post #39

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.

I strongly disagree.

Haskell is great in a pure world, but it has an undue amount of friction when in the IO world. It does work in the IO world just fine, but languages like Java handle the actual concerns of the IO world better than Haskell. And for that reason, I say that no, Haskell is not the one true way to write correct code.

It definitely is the One True Way to write happy path code though.

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

#86

Post by kylewlacy »

tkz1312 wrote: post #47

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. 1: https://garn.io/

I think garn is really cool! If I were still in the Nix ecosystem, garn would probably be my go-to

Building something on Nix obviously has a ton of benefits: well-proven tooling, lots of mindshare already, TONS of packages. Everyone knows that Nix-the-language is fairly unintuitive for beginners, and tools like garn, Devenv, Devbox, etc. all seem to be trying to let folks use Nix without exposing them to Nix-the-language. I think this is a good goal to have and helps make Nix more accessible

But I really thought it was worth exploring the Nix-free design space too. For example, I think derivations in Nix are... kinda complicated and weird! Having a fixed set of phases specifically designed for autotools builds always seemed a little weird to me. By ditching Nix, I was able to see what the world looks like when you ditch the idea of phases completely, for example

Another interesting one was ditching the absolute path for the store path. Getting everything working by resolving relative paths was surprisingly tricky, but the end result is that you don't need to be root to install Brioche, and you can also take a Brioche-built binary (along with the resource dir it outputs) and ship it to another Linux machine and it'll just work. That's only something you can do if you see what happens if you explore outside the Nix space

So I'm hoping Brioche can _at least_ be an interesting case study in how you can take a lot of Nix's ideas and get a lot of the same value without having to take Nix's approach directly (or who knows-- maybe some of those ideas end up back in Nix someday!)

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

#88

Post by barfbagginus »

jhoechtl wrote: post #72
barfbagginus wrote: post #65

Earlier quoted context omitted.

Be like your father except with knowledge of Category Theory That's the best we can do.

The Ops comment was well versed, educated and contributed to the problem. What do you want to tell us with category theory and how does your comment fit into the discussed problem?

Op told a story about his dad, who was a cool guy. My dad was like him too. OP also said he's like his dad because nix goes over his head. That's where I disagree. I think op feels that way only because op doesn't know enough category theory.

I also feel my dad doesn't understand or value abstract things because his Romanian communist math education - as an engineer - fell short of category theory. If he knew categories, we could connect about many more things, but he does not, and this is a massive disconnect that makes my dad unable to apply abstract math to the real world

I was projecting that onto op and suggesting the best we can do is to not be short sighted like our fathers. I self-taught category Theory after dropping out from the math program two times. It changed my life, and let me enjoy math again after burnout and homelessness. And it opened my eyes to many applications of math I never knew about.

My suggestion is that if op learns category theory and the functorial semantics of programming languages, systems like nix will become usable, instead of imposing.

And I am not wrong

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

#89

Post by zarathustreal »

hexo wrote: post #58
zarathustreal wrote: post #39

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.

nix does not have haskells semantics

Yes it does? Purely functional, lazily evaluated.. declarative emphasis. Yea all it’s missing is strong typing, which is why I said it’s similar, not the same.

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

#90

Post by from-nibly »

Sadzeih wrote: post #82
from-nibly wrote: post #78

Earlier quoted context omitted.

No it cant overwrite values. It has to agree or it will throw an error. You can have wider types being overridden by more closed types. e.g. string => "this literal". But you cant have two disagreeing values. I use this to create kubernetes manifests at work, at a reasonably large scale. The inability to join multiple files without fear of collision is specifically one of the best features.

As someone who works with Kubernetes every day and has been curious about CUE for some time, can you describe a bit how you're using it to create manifests? Did it replace helm for you? Or is it to create CRDs? Edit: I'm struggling to see where it fits in the whole k8s ecosystem.

It creates all the stuff that isnt in helm charts already for me. Im probably abusing it at the moment but ill see if I can make a gist and post the link. Bascally though I have a single massive package with a monolithic object. That goes env -> namespace -> resourceName -> resourceType -> resourceManifest.

Then I have a tool file that loops through that and renders it into fall files. Then argocd picks that up in chunks with application files.

Its awesome cause it lets me set project wide defaults and restrictions. It also lets me do stuff like. "If there is at least one manifest called x create an argocd application for it automatically" or " loop through these repos and create an app for each one with the following properties"

Post reply on HN