Live data from Hacker News

Show HN: Devbox – Easy, predictable shells and containers

github.com

31–40 of 196 posts

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

#31
This looks really cool! Can you explain the differences between `asdf` and the .tool-versions file?

I can currently add a .tool-versions file in my project folder and run `asdf install` to get everything on the same versions for all our devs.

    elixir 1.13.4
    erlang 24.3.4
    nodejs 16.4.2

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

#32
post #19
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?

It uses the Docker CLI to build container images out of the Nix shells it creates, if you ask it to export one to a Docker image for you. Otherwise it just uses Nix locally, no virtualization.

I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.

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

#33
post #30
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…

Hmmm, I'll be keeping an eye on this one then!

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

#34
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.

This is a cool project and yay nix, but: > Inside a container the file system is very slow Because you are not using "a container". You are using a container that happens to be running in a linux VM on your OS X laptop. It's not the containers fault, it's the entire virtual machine that you are running because you're trying to run technology built on top of one operating system while running a completely different on…

This. Put another way: it's slow only because you're on macOS and not on Linux.

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

#35

This looks really cool! Can you explain the differences between `asdf` and the .tool-versions file? I can currently add a .tool-versions file in my project folder and run `asdf install` to get everything on the same versions for all our devs. elixir 1.13.4 erlang 24.3.4 nodejs 16.4.2

nix is in some ways a much more refined version of asdf. asdf is basically a wrapper around curling install scripts to bash. It can do anything--it might download a precompiled version of a tool, or it might build the tool entirely from scratch on your machine. It's up to whoever wrote the asdf package, and the quality of the packages there varies _a lot_.

nix goes the next step and has packages defined as an install script plus all their dependencies (all the way down to the basic C library, compilers, etc.). It caches everything based on a hash and provides a public repository where it will just download prebuilt versions of things instead of compiling them from scratch every time. It can do this because it has extremely strict hermeticity and reproducibility guarantees for all of its packages--asdf has none of this and you'll almost certainly just be compiling tools over and over or pulling down pre-built versions that will probably work (as long as you carefully read the package readme and installed all its dependencies).

Don't get me wrong, asdf is nice and great for simple things. If it works for you keep using it. If you start to run into trouble with the quality of its packages or you start writing your own packages, you might want to look at a more comprehensive system like nix.

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

#36
post #24
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 i…

A clarification: the config file is currently exposed as plain JSON file. Cue is used internally because we use it to validate the schema after the JSON is parsed – but currently not exposed to users.

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

#37

Earlier quoted context omitted.

This is a cool project and yay nix, but: > Inside a container the file system is very slow Because you are not using "a container". You are using a container that happens to be running in a linux VM on your OS X laptop. It's not the containers fault, it's the entire virtual machine that you are running because you're trying to run technology built on top of one operating system while running a completely different on…

This. Put another way: it's slow only because you're on macOS and not on Linux.

Totally fair.

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

#38
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.

File systems inside the container aren't slow unless you're running on Windows or some other virtualization platform that makes it slow.

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

#39

This looks really cool! Can you explain the differences between `asdf` and the .tool-versions file? I can currently add a .tool-versions file in my project folder and run `asdf install` to get everything on the same versions for all our devs. elixir 1.13.4 erlang 24.3.4 nodejs 16.4.2

`asdf` shells out to a bunch of different language-specific package managers. `devbox` only shells out to Nix, which manages system dependencies (including native libraries) and language ecosystem dependencies in a uniform way. `asdf` doesn't manage deps like the libraries your nodejs packages that use C bindings for number crunching, or CLI utilities that aren't part of your languages' library ecosystems.

Also devbox can dump Docker containers for you

Post reply on HN