It looks like nearly the same primitives with the same reproducability problems of every non-Bazel, non-nix solution. Why would one learn this instead of just using Nix to create images and getting more actual tangible benefits?
Modus is not really an alternative to Nix as a package manager, but to Nix as a language. It has several advantages, for example, it is non-Turing-complete, so there can not be infinite loops, and its definitions are more concise thanks to its logic programming foundations.
Saying that, I agree that an integration with package managers can be beneficial for reproducibility. This is the area of our current research.
Bazel and Nix stand out as the two things that recently a) I've heard about then initially investigated, concluding that they look promising then b) people who I trust who have used them in depth tell me to avoid at all costs.
Nix is wonderful to use for personal workstations & such. I'd suggest if the idea of purely declaring a package as a function of its inputs sounds interesting to you, it's well worth taking time to look into using Nix.
I think in terms of adopting in a team environment.. I don't think it's a good idea for a company to adopt high-cost-high-reward tools at a place without at least 3 developers who know the technology well. (You don't want just 1 dev knowing it; and you want slack in case 1 quits or whatever).
[nixpkgs the package collection] (which is used by [Nix the package manager], and also contains the [Nix the programming language] expressions that define [NixOS the operating system]) has expressions for easily building OCI images: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTool...
Do you have to be on NixOS to use the OCI images outputtable by nixpks/nix package manager or can you build OCI images using Nix from Mac/Windows/other non NixOS Linux?
They're just normal OCI images, so they can be run by any OCI-compatible container runtime. You can build images from any system running Nix, though you might encounter trouble on non-Linux systems because you may need to cross-compile the packages you use. The build process is exactly the same on any Linux distro (including NixOS and anything else) though.
I think the point is, what trade-offs are you paying such that you'd be better off using Modus, but not a Dockerfile or a Nix expression. -- If you want to benefit from nicer programmatic building of Dockerfiles, and can afford the risk of adopting some non-mainstream technology, you're probably better off trying Nix than this.
No, they really don't. I manage a fleet of hundreds of servers with NixOS. Surprisingly huge companies are using Nix, feel free to look around. I can build for 4 different architectures, with identical system configurations, from a single readable codebase.
I've actually never even heard this particular complaint. What exactly have you heard about problems with nix "at scale", or are you just exaggerating what a "learning curve" is again?
I'm a zealot for pointing out that this tool distinctly doesn't solve what is often cited as a major footgun and misunderstanding of how docker containers are almost always built?
I'll take a learning curve with actual reproducability any day anytime. Add this to the "git is hard" list of complaints. Bending over 8hrs a day and line cooking is harder.
Do you know how many stupid "you're using docker wrong if you don't do this quirky trick!!" articles I've read or written myself over the last 5 years? And still virtually no one bothers to follow all of them because they're virtually impossible to achieve with conventional package managers? Just the zealots noticing this?
eternal wishlist item for container builds: package manager integration. That means per-file caching for library downloads, out of order installation for when you change one thing in your dependency file.
(you can kind of make the caching happen with buildkit but it's annoying to set up)
I'm not sure any layer DAG tool will solve the packaging issue because dags are inherently ordered right?
cloud providers and users are probably aligned here in terms of goals: faster builds, smaller incremental deploys
love this, but sounds from chainguard dev's tweet[1] like these images are single-layer? will that require a full rebuild + full re-transfer on every deploy?
