Closing the Nix gap: From environments to packaged applications for rust

Devenv as a Nix Simplifier and Enhancer

A significant theme in the discussion is how Devenv aims to simplify and enhance the experience of using Nix, particularly for developer environments. Users highlight Devenv's focus on making Nix more accessible and user-friendly, contrasting it with the complexity of pure Nix configurations.

• "We're aiming to take Nix to its most simple form, while devbox uses json for configuration."
• "Think of devenv as systemd of developer environments."
• "If this can work well generally, it's a really slick integration."
• "I'm really impressed with Devenv's velocity and usefulness overall."
• "If you haven't checked devenv out yet, you definitely should. Don't be intimidated by the breadth of the feature set, either! It's really easy to use just the bits you're interested in and grow your usage (or not) organically."
• "Big fan of devenv."
• "I moved away from a Docker-based setup for local development at work to devenv. At least on macOS, the Docker setup was making my machine too hot, and the performance wasn't really the best. With devenv, the transition took a bit of work but the utility and performance is fantastic."

Caching and Build Speed Improvements

The discussion frequently brings up Devenv's ability to cache dependencies in the Nix store, leading to tangible speed improvements in builds. This is seen as a core benefit, especially for projects with extensive dependency trees.

• "Does it cache dependency crates to nix store? Does it result to speed-up in builds?"
• "Yes, it does vendor all the crates to Nix store."
• "It results into speed up in a way that if your application doesn't change, you'll just get the binary package."
• "Yes, it caches compiled crates in the Nix store which significantly speeds up builds, especially for projects with large dependency trees."

Devenv's Relationship with Nix and the Nix Community

A notable part of the conversation addresses concerns about Devenv's relationship with the core Nix project, particularly regarding potential conflicts of interest or "spamming" community spaces. The consensus from those familiar with Devenv is that it is not a fork or competitor, but rather a downstream, complementary project that leverages Nix's strengths.

• "I wish I knew whether Devenv has a conflict of interest with the Nix project. On /r/NixOS on Reddit, some of the people involved in the project just spam submissions related to Devenv instead of helping the community."
• "tl;dr: no."
• "This commenter is just wrong. denenv.nix pretty much is flake.nix + services. It has since grown more features, but this kind of use case is exactly its niche."
• "Devenv isn't a Nix fork and doesn't compete with Nix. Its scope is narrower and it's downstream of Nix. The code you write for configuring Devenv is ordinary Nix code. Its configuration system is a perfectly ordinary Nix module system."
• "There is a devenv CLI tool, and that CLI bundles a downstream soft fork of Nix that carries a few patches. Those patches exist to make it possible to read devenv.nix rather than flake.nix and use an easily programmatically editable yaml file for defining flake inputs. Other than that, all of the patches are just PRs that are open against mainline Nix that are included to speed up evaluation, notably the patchset for 'lazy trees' or 'source tree abstraction' (which is also in the Determinate Nix distribution of Nix)."
• "But you can actually use the core features of Devenv (that is, the module system for configuring environments) without using the Devenv CLI or the patched evaluator. This isn't a hidden thing or a hack, either— it's documented on https://devenv.sh. It's always been this way, and isn't a paywall boundary or a trick. The whole of Devenv is open-source, and the vast majority of the code is Nix modules that you can use with any Nix implementation that you like (though flakes support makes it easier; Devenv's modules are exposed as flake-parts modules)."
• "Hell, you can even use large subsets of devenv's functionality without using devenv at all. One of its key features is a Nix wrapper/integration for the pre-commit framework for managing git hooks. That whole subset of functionality is extremely loosely coupled to devenv, and lives in a separate repo. You can just import it as a flake-parts module with vanilla Nix without using devenv at all (i.e., not even the module system)."
• "There is some code duplication with Nix (optional evaluator patches) and Nixpkgs (downstream release channel for guaranteeing integration with devenv's language configuration options, also optional (my team doesn't use it at all)), but it's extremely misleading to characterize Devenv as a fork of any Nix community projects including those two."
• "Just posting a link to the Devenv website is admittedly not a high-effort reply, but recommending Devenv is absolutely a fair reply to the post you linked. (Given that that post explicitly mentions not wanting to use Devenv, it definitely deserved a real conversation instead of what it got.)"
• "PS: I'm not affiliated with devenv or Cachix. I just use it at work and know the code a little from times that I've filed bugs or submitted patches."
• "I followed this relatively closely and there is no conflict of interest. There is competition, though. With flakes. That’s a good thing in general (competition is good) and in the case of flakes, specifically (flakes are lackluster)."

The Perceived Failure of the Linux Packaging Model and the Role of Abstractions

A tangential but prominent theme revolves around the perceived systemic issues with Linux's approach to packaging and software execution. Some users express frustration with the complexity arising from disparate abstractions and a lack of stable ABIs, viewing projects like Docker as evidence of this failure, while others defend the principle of shipping dependencies.

• "It’s a bloody shame that Linux is incapable of reliable running software programs without layers and layers of disparate, competing abstractions."
• "I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design. The fact that it exists at all is a miserable nightmare."
• "Flatpak and Snap tried to make this better. But they do too much which just introduced new problems."
• "Steam does not have this problem. Download game, play game. Software is not that complicated."
• "The Steam Linux Runtime is pretty bare bones. Their most recent runtime hasn’t been updated in 4 years. That’s quite different."
• "False. The exact opposite of bad."
• "The “system” should provide the barest minimum of libraries. Programs should ship as many of their dependencies as is technically feasible."
• "Oh what’s that? Are crying about security updates? Yeah well unfortunately you shipped everything in a Docker container so you need to rebuild and redeploy all of your hierarchical images anyways."
• "I don't mind stable base systems, I don't mind slow and well tested updates, I actively like holding stable ABIs, but if you haven't updated anything in 4 years, then you are missing bug and security fixes. Not everything needs to be Arch, but this opposite extreme is also bad."
• "And then application developers fail to update their vendored dependencies, and thereby leave their users exposed to vulnerabilities. (This isn't hypothetical, it's a thing that has happened.) No, thank you."
• "So... are you arguing that we do need to ship everything vendored in so that it can't be updated, or that we need to actually break out packages to be managed independently (like every major Linux distribution does)? Because you appear to have advocated for vendoring everything, and then immediately turned around to criticize the situation where things get vendored in."
• "I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed."
• "Many people disagree with that claim and think that TheLinuxModel is good actually. However I point that these people almost definitely make extensive use of Docker. And that Docker (or similar) are actually necessary to reliably run programs on Linux because TheLinuxModel is so bad and has failed so badly."
• "If you believe in TheLinuxModel and also do not use Docker to deploy your software then you are, in the year 2025, a very rare outlier."
• "Personally, I am very pro ShipYourFuckingDependencies. But I also dont think that deploying a program should be much more complicated than sharing an uncompressed zip file. Docker adds a lot of crusting. Packaging images/zips/deployments should be near instantaneous."
• "Does Steam let you control the whole dependency tree of your software, including modifying any part of it and rebuilding from source as necessary, or pushing it to a whole other machine?"
• "Real life software is much more than just downloading a game and running it."
• "Pushing to another machine? Yes. By strict definition. Steam exists to sell pre-compiled proprietary programs for dollars."
• "Rebuilding? No. Linux package management is so-so at allowing you to compile programs. But they’re dogshit garbage at helping you reliably run that program. Docker exists because Linux can’t run software."
• "Real life software outside of Linux is pretty much just downloading and running it. Only in Linux we don't have a single stable OS ABI, forcing us to find the correct package for our specific distro, or to package the software ourselves."
• "Nix is a build system for source code, similar to make. It is such a robust build system that it also can be used as a package manager with a binary cache"