Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
docker-management-container
The Docker Management Container includes a set of plugins and services that make it easier to build, test, deploy and manage infrastructure.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
distrobox
Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
-
A nice porcelain for ad-hoc uses of good ol' `nix-shell`, it looks like: https://github.com/jetpack-io/devbox/blob/main/nix/nix.go#L3...
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 for its own configuration.
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!). 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.
----
Postscript / an aside about CUE
Devbox does still involve a special DSL: CUE. 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.
Remote development will be popular? Yes.
But developing in a monolithic machine may be not. The development environment should be clean and isolated, and products like gitpod and coder is promising.
Besides this, maybe you can have a look at https://github.com/tensorchord/envd and https://github.com/okteto/okteto
It seems to use [Nix](https://nixos.org). In Nix you can use [nix-shell](https://ghedam.at/15978/an-introduction-to-nix-shell) to create a shell with the packages you want. For instance, to create a new shell with Python-2.7:
```
@dloreto @robrich A little aside from the announcement, but since it seems like you both work on this I wanted to surface something that came up down in a subthread:
I'm curious if you attempted to support macOS by doing this with Nix's dockerTools and cross-compiling (there may be better sources, but it's at least hinted at in https://nix.dev/tutorials/building-and-running-docker-images...)? If so, I'm wondering where that failed or bogged down?
---
Background: I build a tool (https://github.com/abathur/resholve) for ~packaging Bash/Shell (i.e., for demanding all dependencies be present). The tool's technically agnostic, but I built it specifically to fix Shell packaging in Nix.
I think it could benefit a lot of other Shell projects, since one of Shell's big tribulations is dealing with heterogenous environments, but most Shell projects wouldn't see much reason to endure the pain of adopting Nix if they still had to support the heterogenous environments.
Much like you're doing here, I've entertained figuring out how to build a Nix-based packaging flow that can generate deployable standalone bundles or containers. It'd be a heavy way to bundle Shell, but I imagine some projects would take the tradeoff for predictability and reduced support load. But since it would need to take place within a Nix build, I'd need to cross-compile for it to work on macOS. Hoping you know if it's a dead-end or not :)
We use something similar at our company, although maybe with not such a nice UX: https://github.com/T-Systems-MMS/docker-management-container
This installs certain tools like helm, terraform or kubectl in the specified version as well as python dependencies or ansible roles and collections in a container to use on your laptop or in cicd-pipelines.
Another nice addition for this is https://github.com/upciti/wakemeops, that provides apt-repository for many tools from the Cloud landscape.
We use something similar at our company, although maybe with not such a nice UX: https://github.com/T-Systems-MMS/docker-management-container
This installs certain tools like helm, terraform or kubectl in the specified version as well as python dependencies or ansible roles and collections in a container to use on your laptop or in cicd-pipelines.
Another nice addition for this is https://github.com/upciti/wakemeops, that provides apt-repository for many tools from the Cloud landscape.
This is one reason I feel lucky to be working with Elixir. Livebook's livemd is basically just markdown. https://livebook.dev
Remote development will be popular? Yes.
But developing in a monolithic machine may be not. The development environment should be clean and isolated, and products like gitpod and coder is promising.
Besides this, maybe you can have a look at https://github.com/tensorchord/envd and https://github.com/okteto/okteto
Um... Interestingly same name, same concept? Down to the use of little box emoji in CLI.
https://github.com/devboxup/devbox
So essentially this seems like another implementation of what toolbox and distrobox is implementing.
https://github.com/containers/toolbox/
https://github.com/89luca89/distrobox
With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?
So essentially this seems like another implementation of what toolbox and distrobox is implementing.
https://github.com/containers/toolbox/
https://github.com/89luca89/distrobox
With the downside of not having the option to select a Linux distro and being locked to the nixpkgs repositories?
If you like the concept you might also be interested in bob[1]. Same idea for build isolation crafted into a build system/task runner. (I'm the author).
[1] https://github.com/benchkram/bob