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 😉
I've been using Nix for over a year now and my biggest mistake at the start was not to take the time to learn the language first. Once I grokked the basics after just spending an hour learning it, it all started to fall into place. I didn't even know it was 20 years old already. Yeah the docs are really bad... hopefully the initiatives taken recently will solve this over time. I liked what I had discovered so much that I threw out my ansible setup for my dev machines (mostly debian and macos systems) and rewrote everything using home-manager and nix-darwin. This made my setup uniform on my work and home machines and totally reproducible. New machine, no problem, 30 mins later back to coding. New starter on boarding, no problem... that is if you are willing to but a little time and effort in, but the time spent pays back dividends in future time saved. Also, numtide devshell, similar to devbox, makes project setup a breeze, with less of an abstraction. Throw in direnv and you're off to the races... oh, using direnv will also combine shell history, so you can use commands across shells... Devshell uses toml files in addition to nix files... not so thrilled at devbox's choice in using json... nix is really not that hard to use to define similar data structures... "But it works on my machine" - turns into "It works on my machine", "And mine" and " On mine too!" Welcome to the club :)
Great video! Especially good at addressing the shortcomings of Nix (at least as perceived by those outside that cult ;-) ), but playing to its strength! I truly like the idea of how to use Devbox as a "sysadmin"/platform engineer/whateveryourcurrentjobdescriptionis .
As I said in a previous reply to this thread (that magically disappeared) I prefer numtide devshell combined with direnv. Devbox used with direnv would be a more streamlined experience than just on its own...
@@c_kemper CZcams sometimes removes comments with URLs or words it thinks should be blocked. It often does not even notify channel owner (in this case me) that it deleted a comment. I'm writing this only to ensure you don't think it disappeared because I removed it.
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.
@19leinad87 it can be both. You can package everything into an image and spin it up as devcontainers. If that's what you always do, Nix is probably a waste. But if you sometimes work locally, sometimes remotely (e.g. devcontainers), sometimes run pipelines, etc. Nix packages are a great choice. Nevertheless, packaged does somehow compete with container images so if you always do everything in containers, you do not need nix.
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.
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.
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!
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.
Nix packages for devbox are the same as for nix. Since they are community managed, some might not be in the best shape. However, since most of them are automated most should be relatively up to date.
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?
Yeah. Using images should be faster. There's also an option to cache nix packages which provides a similar startup speed as images. As a side note... You can build images with devbox.
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?
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.
Unfortunately, I haven't been working with Python for a while now so I'm not sure why it's causing you issues. What I can say is that I haven't had similar problems with languages I use (mostly Go).
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.
It all depends on the benefits. For example, I do use AWS heavily. I am locked in (it would cost me to move elsewhere) but the benefits are much bigger than if i would be on-prem. On the other hand, I feel that the benefits of using Lambda are not as big as the cost of moving elsewhere. At the end of the day, everything we use locks us in. The question is only to make benefits vs. cost estimation. In case of Nix, if you're the only one using it, use any variation you feel is good for you. If many in your company will be using it, find out which variation works for them.
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...
I had issues with gcloud and it took me a while to figure it out. It certainly has its own set of issues but, more often than not, those are issues of Nix packages themselves so finding solutions tend to be faster outside devbox by searching for a similar issue with nix.
I haven't used Flox (just yet) so I cannot compare them. The only thing I know (for now) is that Devbox seem to have more activity than Flox (more stars, forks, contributors, commits, etc.). That does not mean that Devbox is better than Flox but only that's the only thing I noted for now (until I dive into Flox).
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.
I tried nix due to this video, looks like it has bad very swift support(still on 5.8 too), many simple things in clang, llvm are simply broken (I found issues which are pretty old), This is reason i use Fedora and Enterprise Linux(RHEL, Alma), they employ many core maintainers of packages i care about so it is well tested, also many companies test their changes with them, so it doesn't break :/
hasn't eclipse done basically the same 15-20 years ago? ;) Plugins, a repository with a solala search, workspace specific tools, scripts, identical setup across developers... it's funny how our industry works in cycles. next stop: modular monolith applications.
Our industry does work in cycles, but each cycle is based on the experience from prior cycles so, more often than not, new cycles are based on better foundations.
Devcontainers run remotely and while I do tend to use remote services for much of what I do, I never got used to them for dev envs. For me, Nix (and through Nix devbox) tend to be much more comfortable. I need to start a shell session anyways and this just happens to be a shell session with all the tools I need for a specific project.
@@DevOpsToolkit I'm confused. Dev Containers run locally as well as remotely, and VS Code has a nice terminal. They make great local development environments, and they're completely isolated in the container.
Running environments in containers have some annoying gotchas that doesn't make it suitable for a "ephemeral tool install". Isolated file systems comes to mind for a start.
to be fair, task is literally a hilarious edge case. there are thousands of different options. while yes, it should have some parity between the results you get with just e.g. using the web app, i will say, that using this search functionality is leagues better then the PoS nix search functionality. Literally the worst C++ programming on the planet.
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 😉
Thanks for this video. One of the coolest finds in a while. I'm seriously considering replacing devcontainer with devbox for my local development.
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?
I've been using Nix for over a year now and my biggest mistake at the start was not to take the time to learn the language first. Once I grokked the basics after just spending an hour learning it, it all started to fall into place. I didn't even know it was 20 years old already.
Yeah the docs are really bad... hopefully the initiatives taken recently will solve this over time.
I liked what I had discovered so much that I threw out my ansible setup for my dev machines (mostly debian and macos systems) and rewrote everything using home-manager and nix-darwin. This made my setup uniform on my work and home machines and totally reproducible. New machine, no problem, 30 mins later back to coding. New starter on boarding, no problem... that is if you are willing to but a little time and effort in, but the time spent pays back dividends in future time saved.
Also, numtide devshell, similar to devbox, makes project setup a breeze, with less of an abstraction. Throw in direnv and you're off to the races... oh, using direnv will also combine shell history, so you can use commands across shells...
Devshell uses toml files in addition to nix files... not so thrilled at devbox's choice in using json... nix is really not that hard to use to define similar data structures...
"But it works on my machine" - turns into "It works on my machine", "And mine" and " On mine too!"
Welcome to the club :)
Great video! Especially good at addressing the shortcomings of Nix (at least as perceived by those outside that cult ;-) ), but playing to its strength! I truly like the idea of how to use Devbox as a "sysadmin"/platform engineer/whateveryourcurrentjobdescriptionis .
I think pairing Devbox, with Direnv might actually be the ideal setup.
As I said in a previous reply to this thread (that magically disappeared) I prefer numtide devshell combined with direnv. Devbox used with direnv would be a more streamlined experience than just on its own...
@@c_kemper CZcams sometimes removes comments with URLs or words it thinks should be blocked. It often does not even notify channel owner (in this case me) that it deleted a comment.
I'm writing this only to ensure you don't think it disappeared because I removed it.
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.
Is devcontainers an alternative or a complement to nix?
@19leinad87 it can be both. You can package everything into an image and spin it up as devcontainers. If that's what you always do, Nix is probably a waste. But if you sometimes work locally, sometimes remotely (e.g. devcontainers), sometimes run pipelines, etc. Nix packages are a great choice. Nevertheless, packaged does somehow compete with container images so if you always do everything in containers, you do not need nix.
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.
That's exactly what I'm doing and the main reason i like it.
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.
love the editing (one of the best videos!)
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!
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.
Nix packages for devbox are the same as for nix. Since they are community managed, some might not be in the best shape. However, since most of them are automated most should be relatively up to date.
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?
Yeah. Using images should be faster. There's also an option to cache nix packages which provides a similar startup speed as images.
As a side note... You can build images with devbox.
Nix is like a cult LOL ... loved the video dude
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?
You would need to create your own nix package and host it in your registry.
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.
Unfortunately, I haven't been working with Python for a while now so I'm not sure why it's causing you issues. What I can say is that I haven't had similar problems with languages I use (mostly Go).
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.
It all depends on the benefits. For example, I do use AWS heavily. I am locked in (it would cost me to move elsewhere) but the benefits are much bigger than if i would be on-prem. On the other hand, I feel that the benefits of using Lambda are not as big as the cost of moving elsewhere.
At the end of the day, everything we use locks us in. The question is only to make benefits vs. cost estimation. In case of Nix, if you're the only one using it, use any variation you feel is good for you. If many in your company will be using it, find out which variation works for them.
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...
I had issues with gcloud and it took me a while to figure it out. It certainly has its own set of issues but, more often than not, those are issues of Nix packages themselves so finding solutions tend to be faster outside devbox by searching for a similar issue with nix.
How does Devbox compare to Flox? Their aims sound quite similar.
I haven't used Flox (just yet) so I cannot compare them. The only thing I know (for now) is that Devbox seem to have more activity than Flox (more stars, forks, contributors, commits, etc.). That does not mean that Devbox is better than Flox but only that's the only thing I noted for now (until I dive into Flox).
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.
I tried nix due to this video, looks like it has bad very swift support(still on 5.8 too), many simple things in clang, llvm are simply broken (I found issues which are pretty old), This is reason i use Fedora and Enterprise Linux(RHEL, Alma), they employ many core maintainers of packages i care about so it is well tested, also many companies test their changes with them, so it doesn't break :/
I wish they choosed better name, why eval is too slow ?
I'm already in the cult so I'll just use a flake
Oh yeah. If you're already working with Nix and understand its syntax, there is no strong reason to use Devbox.
hasn't eclipse done basically the same 15-20 years ago? ;) Plugins, a repository with a solala search, workspace specific tools, scripts, identical setup across developers... it's funny how our industry works in cycles. next stop: modular monolith applications.
Our industry does work in cycles, but each cycle is based on the experience from prior cycles so, more often than not, new cycles are based on better foundations.
I'm halfway through this video and it just feels like vs code Dev containers are better for this kind of thing.
Devcontainers run remotely and while I do tend to use remote services for much of what I do, I never got used to them for dev envs. For me, Nix (and through Nix devbox) tend to be much more comfortable. I need to start a shell session anyways and this just happens to be a shell session with all the tools I need for a specific project.
As a side note... You can use Devbox to define DevContainers as well.
@@DevOpsToolkit I'm confused. Dev Containers run locally as well as remotely, and VS Code has a nice terminal. They make great local development environments, and they're completely isolated in the container.
@@DevOpsToolkit also, it makes sense to use dev environments like this if devs are already in vs code.
Running environments in containers have some annoying gotchas that doesn't make it suitable for a "ephemeral tool install". Isolated file systems comes to mind for a start.
to be fair, task is literally a hilarious edge case. there are thousands of different options. while yes, it should have some parity between the results you get with just e.g. using the web app, i will say, that using this search functionality is leagues better then the PoS nix search functionality. Literally the worst C++ programming on the planet.