That's a valid perspective, but claudebox isn't my own take. It's Linux user namespaces using bubblewrap to achieve VM-grade sandboxing and near native-level DX with the ability to express your environment using Nix.
Most of those dime-a-dozen solutions employ Docker, so if you like to work inside a container, that's great.
that's still largely a "container" or "sandbox", using the same kernel features, and some package / provisioning manager
I use Dagger, which is BuildKit based underneath, and aligns closely with Dockerfiles, but is far more flexible and is accessible from many programming languages
so in this sense "it's not my own take", but both of these are our own "take" on assembling several pieces of technology to realize a certain application feature. It's the feature that is the "dime-a-dozen" and most people largely don't care what technologies you choose to deliver that feature
This allows you to not only run current commands in a containerized environment, but also any point in history
> .go-version
I would not call this idiomatic Go, you can get the version my project requires from my go.mod file. Imo, a single file with the inputs your tool needs would be preferable to a bunch of files with a single line, but ideally it can infer that on it's own by looking at the language files that already exist
https://github.com/numtide/claudebox
> Intercepts all commands via Node.js instrumentation
these are a dime a dozen now, many different takes, I have my own too
That's a valid perspective, but claudebox isn't my own take. It's Linux user namespaces using bubblewrap to achieve VM-grade sandboxing and near native-level DX with the ability to express your environment using Nix.
Most of those dime-a-dozen solutions employ Docker, so if you like to work inside a container, that's great.
that's still largely a "container" or "sandbox", using the same kernel features, and some package / provisioning manager
I use Dagger, which is BuildKit based underneath, and aligns closely with Dockerfiles, but is far more flexible and is accessible from many programming languages
so in this sense "it's not my own take", but both of these are our own "take" on assembling several pieces of technology to realize a certain application feature. It's the feature that is the "dime-a-dozen" and most people largely don't care what technologies you choose to deliver that feature
This weekend I got Gemini to do the same for me by scripts but in Firecracker VMs rather than Docker
Thanks for sharing, works well
I've been working on something similar, but geared towards integration with VS Code. Builds on CUE + Dagger via https://github.com/hofstadter-io/hof/tree/_next/examples/env
This allows you to not only run current commands in a containerized environment, but also any point in history
> .go-version
I would not call this idiomatic Go, you can get the version my project requires from my go.mod file. Imo, a single file with the inputs your tool needs would be preferable to a bunch of files with a single line, but ideally it can infer that on it's own by looking at the language files that already exist
[dead]