Nix for Everyone: Unleash Devbox for Simplified Development

Simplify your development game with Devbox acting as a simplification layer on top of Nix. Use it to install all the tools required to work on a project and create ephemeral environments that can run as local Shells, remotely as DevContains for GitHub CodeSpaces or DevPod, in Docker containers, or in CI/CD pipelines.

#NixOS #Devbox #DevelopmentTools #EphemeralEnvironments

▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬

▬▬▬▬▬▬ 💰 Sponsorships 💰 ▬▬▬▬▬▬

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬

▬▬▬▬▬▬ 🚀 Other Channels 🚀 ▬▬▬▬▬▬

▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Problems with Nix
04:11 Run Devbox
07:02 Search and Define Devbox Packages
11:00 Working in a Devbox Shell
14:20 Run Scripts with Devbox
15:50 Using Devbox In DevContainers, Docker Containers, and DirEnv
16:44 Devbox Pros and Cons

[IndigoVFX]

Great video Viktor, as a relative newcomer to nix the first hurdle I hit was what the name was referring to – the package manager, the language or the OS built using the first two.

Once I realised the power of a system built from the ground up for idempotency, I took the red pill and rolled up my sleeves just enough to understand how it would help me with my goals of easy reproducibility.

Though I’m not quite there yet, it’s worth sticking with. As another commenter said, they’ll just use a flake, it’s true once it clicks it is that simple – and I too am just a mere mortal.

I’ll concede devbox has piqued my interest so I’ll be taking a closer look, especially as you explained clearly how technologies build on one another.

As for the question of nix being a global package manager, that’s the point. You store the definition of what you want identically reproduced in your dev environment in the project git repo, and if you’re using direnv and .envrc when you cd into the directory in the background nix handles reproducing the exact environment including adjusting your PATH whilst in the project.

Yes it’s like hitting an ice wall at first trying to wrap your head around it, but its usefulness extends far beyond dev environments.

Check out Gabriella439 on GitHub NixOS in production. Or ryan4yin nixos-and-flakes-book – both are excellent resources.

Oh and atuin.sh will solve your history problem 😉

[DevOpsToolkit]

Do you, like me, see the potential in Nix but also backing off due to its complexity? Do you think Devbox might be the "wrapper" we need?

[ymy]

Thanks for this video. One of the coolest finds in a while. I'm seriously considering replacing devcontainer with devbox for my local development.

[joebowbeer]

Thanks for continuing to educate about nix et al. FWIW, I run "arkade get" to install k8s tools locally (e.g., see timoni's installation docs), and I use the "arkade-get" action to install in CI/CD. arkade is not nearly as powerful as devbox but it is more integrated with GitHub releases, so it is can install release candidates, and it doesn't need nix.

[IvanRizzante]

Thanks for another great video! It feels like home to me since I'm already used to DevPod and devcontainers which enabled remote development for me, this could complete the circle for a local ephemeral environment.

[sarafarcic-utgg]

love the editing (one of the best videos!)

[luccapessoa]

I like the idea of working with devbox. I can create a file for each project and facilitate the startup of any new collaborator within that context, recommending that they run the devbox command and shell to have all the tools we can work with in that project.

[strathausen]

Thanks for the great video, I'll give devbox a try ASAP! Just my two cents: personally, I think having the histories isolated is a actually good thing!

[dnsh]

Nix is like a cult LOL ... loved the video dude

[Roman-zsqm]

Thanks for the video, because of it I’ve been using devobx for the past two months and loving it.
Regarding CI pipelines, wouldn’t prebuilt container images be better and faster to compared to having devbox download packages each time the pipeline ran?

[PaulGilowey]

Thanks Victor - devbox looks great! I have a question after watching you 10 CLIs you can't live without video. 

I guess you won't install utils like bat and eza into/with devbox because then your alias of cat and ls won't work unless you're in devbox shell? What would you install with/in devbox, and what would you install on your machine? Or, would you install tools you want to alias into both so that they're portable for other developers using a project's devbox.json?

[dulanjala]

for command history, setup "atuin" an external command history tool... so you have same history in different places, sync-ed even in different systems, i use it to manage lots of servers, even though scripts can help centralize things, when things break and you have to get into the server and debug things, not having mostly used commands sucks..

[nenharma]

This is very cool. I will adopt this and see where it goes. It seems to me that this isn’t very popular yet and even some of the Nix packages seem outdated. That’s a bit worrying tbh.

[chrishillery]

This looks awesome for a number of use cases I have. One question: is it possible to define your own packages, for eg. distributing internal tools? Would that require building complete NixOS packages and running your own nix package registry?

[rwz]

I looked at devbox and devenv, like both but am afraid of the vendor lock-in.
With devenv you are at least closer to nix standard.

What are your thoughts on vendor lock-in.

[AngriestEwok]

I tried installing Jupyter notebooks on vscromium in my dev environment using devbox. It just doesn't work. Even if I use Nix packages for all my python packages (which is a really nasty way to do things, BTW), it still won't find the right c++ libraries when you try and create a kernel for jupyter.

[patpatisserie]

How does Devbox compare to Flox? Their aims sound quite similar.

[TomerShaiman]

There is a slight challange when using DevBox with python, sometimes you get an error such as "This environment is externally managed" so it does not response well to pip3 install when done inside the devbox

[jaredhancock]

Devbox is awesome, but still has some quirks. For example, if I have golang 1.20 installed on my host shell, while Devbox installs golang 1.22, there's still a risk of getting "unknown toolchain" errors when compiling 1.22 go modules. I guess it's due to how env variables can collide between the two shells. Haven't had time to fully troubleshoot it yet...

[DryBones]

This looks promising. I'll have to take a deeper look at the features to determine if it is worth adopting. So far I use a pretty simple shell.nix file which just lists the packages and an init hook for adding bash scripts to path. Anything more complex than that and I imagine I'd be getting into the nix weeds a bit which justifies devbox.