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

131–140 of 196 posts

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

#131

Post by chupasaurus »

dloreto wrote: post #30
nidnogg wrote: post #22

Earlier quoted context omitted.

> 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's actually not since BuildKit could be run as a standalone daemon, and you can run the result via containerd which is a dependency of Docker. Might write a PR over the weekend(s).

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

#132

Post by gamjQZnHT53AMa »

baby wrote: post #127
xvector wrote: post #21

Earlier quoted context omitted.

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…

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)

This looks great. As someone who started learning Nix in the last few weeks this is definitely needed and will prove invaluable to future learners. I'm still completely lost on a lot of things but if I work something out that isn't covered on your site I'll try and put together a PR for it.

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

#133

Post by Foxboron »

alecthomas wrote: post #125
Foxboron wrote: post #124

So essentially this seems like another implementation of what toolbox and distrobox is implementing. https://github.com/containers/toolbox/ https://github.com/89luca89/distrobox With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?

No, it uses native Nix directly on your machine - Linux, Mac, or Windows. Its integration with Docker is that it can _build_ Docker images from the Nix packages in your "devbox".

It's the same abstraction layer though. The implementation for all three is bound to be different.

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

#134

Post by KingJulian »

kreetx wrote: post #109
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?

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

This is where version pinning comes in. Most base images use specific versions of packages.

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

#135

Post by shirogane86x »

alecthomas wrote: post #125
Foxboron wrote: post #124

So essentially this seems like another implementation of what toolbox and distrobox is implementing. https://github.com/containers/toolbox/ https://github.com/89luca89/distrobox With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?

No, it uses native Nix directly on your machine - Linux, Mac, or Windows. Its integration with Docker is that it can _build_ Docker images from the Nix packages in your "devbox".

I'm assuming for windows it only works in WSL2? cause last time I checked nix wasn't compatible with native windows development, sadly

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

#136

Post by pramodbiligiri »

regularfry wrote: post #114
pmontra wrote: post #89

Earlier quoted context omitted.

That is how I and everybody else were developing software at my university around 1990. A few HP servers, character terminals or X11 servers. Then everybody got a Windows desktop at home powerful enough to work as on those X servers and it was game over. I never saw a company developing on a shared server. Do you work for one doing that? In that environment I expect developers to need separate environments not to sto…

I've worked at a company where we used a shared server, relatively recently. Isolated environments were different /home directories and agreed port ranges. Actions that interfered with other folk were mistakes that happened once, because we were (for the most part) not a bunch of raging arseholes and were capable of talking to each other like adults. It was a lovely environment to work in, in part because sharing our…

This sounds fascinating. What was the config of that beastly dev machine, if you can tell?

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

#138

Post by TheCapeGreek »

mhio wrote: post #129
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 Out of interest, what in your dev process makes using containers so impactful?

Docker on Mac and Windows runs in a VM, not natively.

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

#139

Post by PhilipTrauner »

throwaway892238 wrote: post #47

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…

I agree with the need for a standardized development setup (be it local or in the cloud) but violently disagree with eliminating development setup diversity.

Curious engineers with oddball configurations greatly contribute to the overall health of a codebase. Forcing these folks to use a standardized configuration is a missed opportunity at best, and disgruntling at worst.

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

#140

Post by lozenge »

mhio wrote: post #129
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 Out of interest, what in your dev process makes using containers so impactful?

They probably want their source code on their "real" filesystem which makes Docker painfully slow.
Post reply on HN