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

Show HN: Devbox – Easy, predictable shells and containers

github.com

Post reply on HN
Print view View original

161–170 of 196 posts

Re: Show HN: Devbox – Easy, predictable shells and containers

#161

Post by stavros »

methyl wrote: post #141
stavros wrote: post #56

I want to love this, and it looks amazing, but it doesn't work for me: 05:01:13 $ devbox add python2 Error: Package python2 not found. Really bad first-run experience when the demo command doesn't work, sadly.

This error happens because you didn't spawn a new shell after installing nix and devbox. I think README could make it more obvious, as I stumbled upon this as well.

I did, I was using the wrong Nix package, turned out. In the end I ended up curl | bashing it, and it worked. I really like this project, just needs a bit of love in the error messages.

Re: Show HN: Devbox – Easy, predictable shells and containers

#162

Post by matnosner »

jitl wrote: post #15

Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…

If you like the concept you might also be interested in bob[1]. Same idea for build isolation crafted into a build system/task runner. (I'm the author).

[1] https://github.com/benchkram/bob

Re: Show HN: Devbox – Easy, predictable shells and containers

#163

Post by zie »

x0rg wrote: post #96
zie wrote: post #92

Earlier quoted context omitted.

nix-shell would happily run inside of any container, vm, etc.

I run nix in a vm all the time. The point of this project seems to be to avoid this approach and use local dev natively, which would be a godsend. I am pointing out that there are a bunch of things that are not really supported or ideal with the chosen nix-shell based approach.

Don't let perfect be the enemy of good comes to mind :)

Re: Show HN: Devbox – Easy, predictable shells and containers

#164

Post by ParetoOptimal »

xvector wrote: post #21
jitl wrote: post #15

Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…

Nix absolutely needed a wrapper like this to be used 'in the real world.' When you think about bringing it to production (eg getting dev teams to migrate to it), Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form. I spent hours converting my devboxes to NixOS and managing my…

> Nix goes from a genuinely interesting idea to an "oh, that's cute" experimental toy because no one is going to spend hours learning Nix's weird DSL. It's simply not approachable in its base form.

Here's an opposite opinion:

> My hot take is that Nix actually has great syntax

> In particular, the way Nix handles record syntax is exemplary and more languages should copy what Nix does in this regard

And even more related to this discussion:

> A lot of the times, when people say they hate "Nix's syntax", what they more likely mean is that they hate the domain-specific languages of the Nixpkgs overlay system and/or the NixOS module system

https://mobile.twitter.com/GabriellaG439/status/156300116656...

Re: Show HN: Devbox – Easy, predictable shells and containers

#165

Post by ParetoOptimal »

unicornmama wrote: post #147
baby wrote: post #127

Earlier quoted context omitted.

My theory is that we need better learning resources (that’s why I’m working on https://mimoo.github.io/nixbyexample/ ), better tooling (debugging or starting a project from scratch is hard), better integration with rust/js/etc. projects based on convention (and not configuration: I shouldn’t have to point to more than a Cargo.toml or package.json and nix should do the rest)

The problem is boundless complexity. Learning resources won’t help anyone to learn and manage boundless complexity.

Are you really claiming Nix has boundless complexity?

Re: Show HN: Devbox – Easy, predictable shells and containers

#166

Post by ParetoOptimal »

idontwantthis wrote: post #68
jitl wrote: post #15

Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…

I just set up a docker dev environment on Mac and I would not call it slow anymore. If you were referring to volume mounts, they are 10x faster now. Definitely fast enough for our work.

> they are 10x faster now. Definitely fast enough for our work.

They are definitely faster and great improvements.

But when I can use Linux through qemu and compile my companies Haskell application in 45s rather than 3m30s...

The choice is obvious to use Linux.

Re: Show HN: Devbox – Easy, predictable shells and containers

#167

Post by ParetoOptimal »

xlix wrote: post #19
vhanda wrote: post #13

Earlier quoted context omitted.

I haven't run devbox, but the README says that it requires docker to be installed. This makes me believe it isn't running the programs on my system (macos), but rather in the Linux VM.

so an abstration on top of docker?

No, it just creates images compatible with docker.

Re: Show HN: Devbox – Easy, predictable shells and containers

#168

Post by ParetoOptimal »

pinglin wrote: post #146
kreetx wrote: post #109

Earlier quoted context omitted.

Dockerfiles are repeatable but they are not reproducible - they don't give you the same version of everything every time you run them.

One can absolutely lock versions in their Dockerfile. I can see that the design principle of DevBox is to pin the versions. At the end of the day we all need to consider versioning (i.e., the image version) the versions (i.e., package versions) anyway.

Reproducible Docker is fighting an uphill battle, Nix and it's ecosystem tries to be reproducible by default.

Dockers ecosystem aims more for repeatable, not reproducible.

> At the end of the day we all need to consider versioning (i.e., the image version) the versions (i.e., package versions) anyway.

The granularity of pinned versions and feasibility of having a culture of everything being pinned versus needing to know a crazy amount of things that need pinned a big difference.

Re: Show HN: Devbox – Easy, predictable shells and containers

#169

Post by ParetoOptimal »

TekMol wrote: post #99

A consistent shell for everyone on the team Declare the list of tools needed by your project via a devbox.json file and run devbox shell. Everyone working on the project gets a shell environment with the exact same version of those tools. Why not just use a Dockerfile?

Smaller docker images for one:

https://grahamc.com/blog/nix-and-layered-docker-images

Nix gives repoducibility, docker gives repeatability but not reproducibility.

Also see the video "Use flake.nix, not Dockerfile": https://www.youtube.com/watch?v=0uixRE8xlbY

you can swim upstream and make your own docker image reproducible, but that doesn't change an ecosystem of images that aren't

Re: Show HN: Devbox – Easy, predictable shells and containers

#170

Post by ParetoOptimal »

abiro wrote: post #153

Wondering how well it integrates with IDEs. Anyone tried it with Intelllij?

For plain Nix the universal work around is to run your editor inside of the nix-shell.

A better option iis a direnv plugin that modifies environmental variables inside of your editor to match your nix shell.

Post reply on HN