Nix is solving the wrong problems, and I'm dismayed that it is being adopted more and more to solve those wrong problems. The very concept of a "development environment" is indicative of broken build systems. Ecosystems like python are trying desperately to tame the insanity using venvs, while ecosystems like rust were built correctly from the start with Cargo. Neither of these benefits in the least way from Nix or the most popular alternative, Docker (except that both end up falling victim to the insanity of other ecosystems when FFI comes into play).
What Nix could have been was a global un-fscked dependency manager, a la Portage but with Nix's special sauce for local environments -- thereby working around fundamentally and permanently broken ecosystems like C, which would be useful even in the FFI case. But somehow it never got around to actually managing dependencies. By failing to manage dependencies (by pretending that versioning doesn't exist, and supporting only exact software sets), Nix only re-entrenches the same bad behavior and broken systems which it should have been replacing: i.e., encouraging "works-on-my-system" build environments, by making them part of mandatory collaboration workflows.
So, soon: Encounter a bug because the build depends on the environment in some inappropriate, insane way? Then it's your own fault for not adhering to the approved Nix build instructions which would set up a system which doesn't exhibit that bug.
There is a lot to unpack here — first of all, Nix and Docker are not at all competitors. Docker doesn’t even try to be reproducible, most builds will just apt install the newest available version that could easily change between invocations.
Next, Cargo is not a solution: it can only do a tiny part of the problem, namely managing Rust dependencies for a Rust project.
What if you are building a tool that needs a shared lib to communicate with.. basically anything? Rust has an enthusiastic community, but it is still a tiny language — most problems require more than what can be found in any one language’s berks.
Also, what even is a version? 3.4 of package X doesn’t mean anything — if it has like 10 flags than it can be built 2^10 different ways, and then we didn’t even count its dependencies that are also not just a number. Nix does the correct thing, not the naive one.
Nix is not about "development environments" (i.e. 'nix-shell'); that's just a side-effect which comes for free. Nix's main entry-point is 'nix-build', which runs a specified executable with specified arguments and environment variables.
(The same applies for the newer 'nix' CLI, but I'm less familiar with that)
I upvoted this even though I largely disagree with it, because I think it deserves discussion rather than downvotes. It's especially interesting to me because parts of it remind me of how I (along with many other Nix users) think of Docker.
> What Nix could have been was a global un-fscked dependency manager, a la Portage but with Nix's special sauce for local environments -- thereby working around fundamentally and permanently broken ecosystems like C, which would be useful even in the FFI case. But somehow it never got around to actually managing dependencies.
I agree. I think Nixpkgs can/should only officially support one combination of packages in a unified collection, up to the point of including pre-built binaries for that exact combination of dependencies in the main community binary caches.
But allowing multiple versions of packages to live in Nixpkgs (or an ancillary repo), automatically marked with version ranges reflecting the versions that those recipes have previously been successfully built against, would greatly simplify searching for and using packages by their upstream versions. The most trivial and most common case for overriding packages— changing the version of the sources to be built— would be obviated, leaving overrides to more advanced use cases like adding patches, changing build flags, adding dependencies, etc.
I think there's still room to grow Nix in this direction, though! The limitation here is incidental rather than fundamental.
> Nix only re-entrenches the same bad behavior and broken systems which it should have been replacing: i.e., encouraging "works-on-my-system" build environments, by making them part of mandatory collaboration workflows.
Not true. There is a problem that can occur where a lot of users or even collaborators on a project don't really know how to build it, or what all of the requirements are. This happens sometimes with projects where Docker is always the expected way to build or deploy. But sussing out the real build requirements from a Dockerfile is hard in a way that doing the same from a Nix package is not! Docker allows for all kinds of non-determinism, and dependencies in Docker can be supplied implicitly (or at least indirectly— you may have to track down how a particular base image was built to figure out if some dependency is assumed to be installed). But things like blocking network access and the prefix hacking in the Nix store ensure, if not guarantee, that the dependencies of Nix packages are explicit.
> So, soon: Encounter a bug because the build depends on the environment in some inappropriate, insane way? Then it's your own fault for not adhering to the approved Nix build instructions which would set up a system which doesn't exhibit that bug.
Nix is great, and it's great when projects offer a flake.nix or a shell.nix. But (1) development communities not knowing what their own requirements are is a cultural problem and (2) I hope and expect we'll see little of this. The kinds of things Nix does to environments that are Nix-specific are generally extremely unlikely to affect program behavior, like setting the date and build time to the start of the Unix epoch.
Have you encountered any projects that depend on Nix-specific behaviors? Or are you mainly worried that the kind of natural vendorization that Nix provides will lead developers to only test their software on narrower and narrower ranges of version combinations?
> Or are you mainly worried that the kind of natural vendorization that Nix provides will lead developers to only test their software on narrower and narrower ranges of version combinations?
I guess, but I would not characterize it as a problem of testing. As I understand it the thing you are "supposed" to do is use the upstream developer's exact dependency tree, unless you override it in which case you've completely voided the warranty as it were. Or, this applies to collaborators across the same project too. This means using whatever broken outdated environment that developer happens to prefer, possibly because of other software on their system transitively requiring ridiculous environments, or because they're just lazy or whatever.
This doesn't apply to software in the blessed set that's kept up to date, but I don't think you get points for being at parity with, say, Ubuntu.
As someone who sometimes uses Nix to put together devShells for small projects at work, I admit there are times I might be inclined to point someone to the flake as a workaround for a versioning issue. But I would still consider it a bug in my app to be broken with a newer version of a library than what I have pinned. I believe many developers must feel similarly!
At the end of the day, when it comes to development environments, Nix should be a way to help provide a reproducible fast track for building and/or running the software, not a preemptive dismissal of all other possible downstream users and distros! If your software has a Nix flake but no build instructions, it's missing documentation. That's probably okay for solo open-source projects that are small and indifferent to building a userbase, but I hope maintainers and companies will readily recognize that as they grow they'll have to fill that gap at some point.
What Nix could have been was a global un-fscked dependency manager, a la Portage but with Nix's special sauce for local environments -- thereby working around fundamentally and permanently broken ecosystems like C, which would be useful even in the FFI case. But somehow it never got around to actually managing dependencies. By failing to manage dependencies (by pretending that versioning doesn't exist, and supporting only exact software sets), Nix only re-entrenches the same bad behavior and broken systems which it should have been replacing: i.e., encouraging "works-on-my-system" build environments, by making them part of mandatory collaboration workflows.
So, soon: Encounter a bug because the build depends on the environment in some inappropriate, insane way? Then it's your own fault for not adhering to the approved Nix build instructions which would set up a system which doesn't exhibit that bug.