We've been using devcontainers for this, as it's already got good support in vscode. Could you perhaps "elevator pitch" the main differences between devbox and devcontainers?
whinvik 18 hours ago [-]
Yes, it feels very similar to Devcontainers.
But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues.
The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet.
So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to mention they have a huge user base via VSCode.
NitpickLawyer 17 hours ago [-]
The killer combo for us is remote+devcontainers. We use this for GPU access, so you can run a project on one or more GPUs that are on a remote server. You can spin up LLM stuff from a mac air and get the best of both worlds.
runelk 17 hours ago [-]
Nice! Do you have any tips or recommendations for a decent setup?
phrotoma 14 hours ago [-]
This has been my experience. I don't use VSCode and every time I've attempted to play with devcontainers I've just given up and gone back to a docker compose file. I love that they tried to extract the feature out into a stand alone thing, but the juice doesn't seem to be worth the squeeze yet.
immutology 5 hours ago [-]
Devcontainers work nicely with docker compose. It's the only way I use it... Really nice to have it all run containers.
Very good question, and even if your product is better it seems like an uphill battle. devcontainers are backed by MS/VS and they have good incentive to make them work.
Why you think your solution will succeed in long run and win over devcontainers?
I think it’s reasonable. What’s another way, “I’m into backdoor stuff”?
swiftcoder 14 hours ago [-]
hey, I mean, buttplug.io could always use the contributors
bryanlarsen 18 hours ago [-]
The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
FireInsight 10 hours ago [-]
Good point. I remember testing out Jetify's version a while back and switching away from it due to some issue I was having. I 100% thought this project was the same, just with a new website, as I did not remember much of the implementation details. Both of them even use `devbox.json` as the configuration file...
gdotdesign 17 hours ago [-]
Also, DevBox (https://www.dev-box.app/) which is a collection of small tools for multiple platforms which I've been building since 2021.
3 hours ago [-]
l___d__s 19 hours ago [-]
FYI there's a well-starred, corporate-backed, similar functionality, Nix-based product with the same name:
I usually don't take name clashes as seriously as some people here do, but when it's even in the same general niche, then that's not really a good look. It means the author failed to check the prior art - which is still fine for a (n+1)th hobby project, but not really for something more serious.
techn00 18 hours ago [-]
I thought that OP linked this devbox since so many subcommands from the cli are almost identical
Why should we use yours? What does it do better or differently?
hk1337 11 hours ago [-]
While this is true, this project seems to wrap it up in a CLI package for starting and stopping projects. Whereas starting devcontainers, at least as far as I have seen, is always done via VSCode or IDE, so while it technically could be called CLI too, would be a lot more complicated than this project.
nickzelei 10 hours ago [-]
The devcontainers cli has existed for a while. Definitely not as smooth as using with vscode but it has all the main points.
One obvious one is that Toolbx and Distrobox are based on Podman, for one.
bogwog 10 hours ago [-]
> One obvious one is that Toolbx and Distrobox are based on Podman, for one.
And as a result, the containers are rootless.
kekqqq 13 hours ago [-]
I had a very strong personal opinion that, unless you expect frequent migrations or horizontal scaling, Docker is overkill and could be considered as bloat in many instances. After I joined my new company, I found out about devbox, and I love it. Now I use it for almost every personal project. It helps you to make the environment reproducible without sacrificing performance.
I always like to see new projects using containers. Two questions:
- how is your devbox.json file different from a Dockerfile/Containerfile?
- does your project attempt to provide any isolation security-wise?
dns_snek 18 hours ago [-]
> does your project attempt to provide any isolation security-wise?
Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.
Plugging my own tool. I use it for development and running semi-trusted or temporary tools, mounts the current/project dir for isolation, and shuts down automatically when it can.
I've been using Docker containers for quite some time to do web dev work. The one thing I haven't yet set up is doing mobile dev in a docker environment.
Does devbox support mobile development - Flutter or ReactNative?
jonotime 12 hours ago [-]
Would love to use something like this for NixOS as an escape hatch, but its debian only. DistroBox always gives me trouble.
exasperaited 2 hours ago [-]
I am afraid that despite all these options for containers, I still use my Vagrant scripts that build whole VMs based on my own schemes, use an apt package cache on the host and manage .ssh/config for me to make VSC remotes more seamless.
Almost all my stuff still runs on simple VMs because I cannot rely on my clients to take on more complex cloud infrastructure and I don't want to be stuck managing all of the things forever, so my life involves building customer VMs from build scripts that are adequately similar to my Vagrant boxes.
I use the VMs a lot for simple tests (e.g. of wordpress plugins and themes) so I have gone to the trouble of setting up Avahi with alias support, adding options for mailhog, different databases, different webserver setups I use for WP or Laravel or node.js, setting up an automated WP install etc.; so there are two or three starting configurations. I even had one for Magento before I realised I could be a lot happier without Magento in my life.
I guess it looks a fair bit like devcontainers now, and I should consider migrating over to that. But it's solid and under my control and that counts for a lot.
tomas789 13 hours ago [-]
OP should consider changing their alias.
clueless 9 hours ago [-]
Amazing amazing project, thank you for sharing this
globular-toast 18 hours ago [-]
I don't get how containers address "dependency hell". Is there some language that only supports installing libraries system wide? I've used a lot of different languages and yet to come across one.
I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reason. All it makes me wonder is what are you afraid of? Why do you feel the need to isolate dev projects to this extent?
wiether 14 hours ago [-]
Isolation works both ways.
By isolating your dev project, you don't expose your host to the mess the project can create... and you don't expose your project to the mess that can exist on your host.
With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to go.
As soon as you're done with this project, you delete the container and not a single trace of the project exists on your host.
No matter how many custom things the project required to run.
neves 13 hours ago [-]
And since you have everything in a configuration file, it is breeze to transform your dev container in a production one.
Gabrys1 17 hours ago [-]
C libraries are easiest to install system wide. The situation with multiple versions of libc is tricky to work with.
Not impossible, just not easy to comprehend by an average dev.
globular-toast 16 hours ago [-]
I'm kinda horrified to think there might be people writing C who don't know how to handle library versions. Somehow I don't think that is the target audience here, by I might be wrong.
Gabrys1 9 hours ago [-]
You might need to install libxml2 in order to use XML parsing library for your high level programming language.
You don't need to be writing C code to be affected by the dependency hell.
parham 17 hours ago [-]
I’ve been doing a version of this using bash scripts for a long time! Thanks for making it
tiku 17 hours ago [-]
It's good that we get more options. I like ddev, will try this as well.
But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues.
The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet.
So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to mention they have a huge user base via VSCode.
https://code.visualstudio.com/docs/devcontainers/create-dev-...
Why you think your solution will succeed in long run and win over devcontainers?
https://containers.dev/
There has to be a better way to phrase this
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
https://github.com/jetify-com/devbox https://www.jetify.com/devbox
Why should we use yours? What does it do better or differently?
https://github.com/devcontainers/cli
I'm not proponent of installing nodejs apps globally, npm install -g or yarn install -g
One obvious one is that Toolbx and Distrobox are based on Podman, for one.
And as a result, the containers are rootless.
However, I use https://www.jetify.com/devbox.
- how is your devbox.json file different from a Dockerfile/Containerfile?
- does your project attempt to provide any isolation security-wise?
Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.
Container Shell - https://github.com/jrz/container-shell
Does devbox support mobile development - Flutter or ReactNative?
Almost all my stuff still runs on simple VMs because I cannot rely on my clients to take on more complex cloud infrastructure and I don't want to be stuck managing all of the things forever, so my life involves building customer VMs from build scripts that are adequately similar to my Vagrant boxes.
I use the VMs a lot for simple tests (e.g. of wordpress plugins and themes) so I have gone to the trouble of setting up Avahi with alias support, adding options for mailhog, different databases, different webserver setups I use for WP or Laravel or node.js, setting up an automated WP install etc.; so there are two or three starting configurations. I even had one for Magento before I realised I could be a lot happier without Magento in my life.
I guess it looks a fair bit like devcontainers now, and I should consider migrating over to that. But it's solid and under my control and that counts for a lot.
I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reason. All it makes me wonder is what are you afraid of? Why do you feel the need to isolate dev projects to this extent?
With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to go. As soon as you're done with this project, you delete the container and not a single trace of the project exists on your host. No matter how many custom things the project required to run.
Not impossible, just not easy to comprehend by an average dev.
You don't need to be writing C code to be affected by the dependency hell.
https://devpod.sh/