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

21–30 of 196 posts

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

#21

Post by xvector »

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 dev environments with home-manager and I still don't have a clue how any of it works. Errors are opaque and annoying to debug. Dev environments constantly break and change in ways that belay the "reproducible" nature of Nix. If someone actively interested in Nix can't easily grasp it, how does anyone expect it to catch on in the real world?

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

#22

Post by nidnogg »

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…

>Of course we could use Docker, but then on Mac our dev process would be 3x slower.

Doesn't devbox depend on Docker, though? I figure any performance losses from Docker would happen with this too.

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

#23

Post by dloreto »

ignoramous wrote: post #18

Thanks. > Devbox was originally developed by jetpack.io and is internally powered by nix. If this wasn't mentioned, I'd have easily mistaken devbox to be an escaped implementation of Brazil VersionSets and Apollo VersionFilters (used internally at Amazon). If I may, in the near-term does jetpack.io plan to continue to use and sponsor devbox's development? And, in the long-term, does jetpack plan to monetize this proj…

Yes, we use it internally for all of our development and plan to continue actively maintaining it. If there's enough interest from the community we would love to make it a Cloud Native Computing Foundation project.

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

#24

Post by pxc »

vogelito wrote: post #5

what is this sorcery?

A nice porcelain for ad-hoc uses of good ol' `nix-shell`, it looks like: https://github.com/jetpack-io/devbox/blob/main/nix/nix.go#L3...

The container export functionality is based on BuildKit via the plain `docker buildx` CLI: https://github.com/jetpack-io/devbox/blob/main/docker/docker...

and it uses CUE to validate its configuration, which is JSON.

All-in-all it actually looks extremely simple. I guess the basic idea is to give you access to a subset of the power of Nix and all the goodies in Nixpkgs without exposing you to the Nix language or the Nix CLI.

Longstanding Nix users will probably not be super excited about this (though they might as well try it! it does look very nice to use). However, for folks who are put off by Nix's reputation for difficulty but might be tempted to enjoy freely drawing upon the 80,000+ software packages in Nixpkgs, this might be a way to have your cake and eat it, too.

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

#25

Post by qbasic_forever »

nicoburns wrote: post #14
dloreto wrote: post #7

Having a deterministic environment, but that is actually running on your laptop is so much better than working inside a docker container. Inside a container the file system is very slow, and you lose all of your other tools and shell aliases.

What I really want is a tool like docker compose that builds on top of a tool like this (instead of docker)

Assuming you want the service management aspect of docker compose look at user-mode process supervisors like supervisord. You can install it in your nix environment and config all the dependent services it should manage. It's a little more crufty vs. the simplicity of docker compose but it also has a lot more power and flexibility. There are tons of other options to explore too like systemd user services or skarnet's s6 suite.

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

#28

Post by pxc »

dloreto wrote: post #8
figomore wrote: post #6

Earlier quoted context omitted.

It seems to use [Nix]( https://nixos.org ). In Nix you can use [nix-shell]( https://ghedam.at/15978/an-introduction-to-nix-shell ) to create a shell with the packages you want. For instance, to create a new shell with Python-2.7: ``` $ nix-shell -p python27 ```

Yes, internally it's using nix .. but it makes nix soooo much easier to use. With nix I've always struggled with the nix language and writing nix expressions. If you are comfortable with nix itself, then it allows you to do a lot more than devbox does, but at the cost of extra complexity. Depends on what level of abstraction you're looking for.

And happily, since this is a front-end rather than an incompatible fork or something, you don't have to choose!

If you wanted you could totally use this most of the time and then write custom Nix expressions only if you felt like that would serve you better. For many use cases, this might be sufficient.

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

#29

Post by Aeolun »

nidnogg wrote: post #22
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…

> Of course we could use Docker, but then on Mac our dev process would be 3x slower. Doesn't devbox depend on Docker, though? I figure any performance losses from Docker would happen with this too.

Only for the build step (e.g. making a docker image). The dev step runs entirely on your machine.

I got that from the README btw, no guarantees :)

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

#30

Post by dloreto »

nidnogg wrote: post #22
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…

> Of course we could use Docker, but then on Mac our dev process would be 3x slower. Doesn't devbox depend on Docker, though? I figure any performance losses from Docker would happen with this too.

The dependency on Docker only exists for when you want to turn your shell into a container – but it's not otherwise used when you're just running a shell locally.

When writing javascript there's often a desire to have "isomorphic" or "universal" applications. Write the code once and run it in _either_ the client or the _server_.

Devbox is taking a similar approach to the development environment: declare it once, run it locally as a shell, and when you're ready, turn it into a container without having to re-declare it. It's only the latter functionality that has a Docker dependency.

Post reply on HN