and it uses CUE to validate its configuration, which is JSON.
All-in-all it actually looks extremely simple. I guess the basic idea is to give you access to a subset of the power of Nix and all the goodies in Nixpkgs without exposing you to the Nix language or the Nix CLI.
Longstanding Nix users will probably not be super excited about this (though they might as well try it! it does look very nice to use). However, for folks who are put off by Nix's reputation for difficulty but might be tempted to enjoy freely drawing upon the 80,000+ software packages in Nixpkgs, this might be a way to have your cake and eat it, too.
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.
Ah, thanks! I've updated my comment to reflect that.
What you describe is also a sensible use of CUE. I suppose if one of your goals is 'avoid asking users to use a language they don't already know', it might be for the best. :)
But personally I wouldn't mind seeing a bit of CUE usage to work with devboxes, hehe.
For continuity, here is my aside on CUE from that comment, apropos of nothing but my lack of reading comprehension :D
----
CUE is, like Nix, a simple, configuration-oriented DSL. But unlike Nix, it's really just extended JSON (a JSON file can be thought of as a CUE file where all of the values are concrete), it has a different kind of type system where values are types, and the language is decidedly not Turing complete. The type system is pretty neat, and the basic idea is that you can put constraints in the place of values, and write data structures that contain mixes of each. Then latter you can apply those constraints to a configuration/specification and CUE will tell you whether they're compatible. It's cool because you can write your specification and your data in the same format.
While CUE is not a full programming language, it does have a small stdlib and basic 'comprehensions' (like list comprehensions in Python) for generating data structures from other data structures. This gives at least a little flexibility and some hope of concision, defining repetitive data structures.
Having used Nix a lot and CUE a little, I'm not sure which set of tradeoffs in terms of power and simplicity is it right one, but I do think that CUE's choices are interesting and reasonable, and its type system is clever and easy to work with.
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 idea is to give you access to a subset of the power of Nix and all the goodies in Nixpkgs without exposing you to the Nix language or the Nix CLI.
Longstanding Nix users will probably not be super excited about this (though they might as well try it! it does look very nice to use). However, for folks who are put off by Nix's reputation for difficulty but might be tempted to enjoy freely drawing upon the 80,000+ software packages in Nixpkgs, this might be a way to have your cake and eat it, too.