Typing on the go so may have missed a param
Typing on the go so may have missed a param
Tbh i've found Nix very very lacking in the dependency department. What i _want_ is something like Cargo.toml from Rust (or maybe packages.json/yarn.lock if you're familiar with NodeJS), which compiles to a Cargo.lock. Instead what i have is a name for a dependency with no clue what version the writer expected, or what version my computer will install.
Pulling a new commit from nixpkgs repo can lead to chaos and random things update with no rhyme or reason.
Flakes, in alpha i believe, is the first thing from Nix that actually felt repeatable. But even with Flakes i still don't know what version anything is, but at least i know what concrete commit sha worked for me and can always revert as needed.
My next NixOS install will use Flakes with a very granular approach. The OS on one package ref, and other packages all have their own isolated refs. This will be verbose and bloaty, but being able to update Vim without my OS going crazy will be really nice.
I'd still like Flakes to behave more like Cargo.lock, but it's at least progress.
As with a lot of comments about Nixlang, the tooling there seems lackluster at best. In this case i'd want tooling to easily know and change package versions, not sweeping changes to your entire package ecosystem. Nix might give me that, but resolving derivations manually is not a great UX, imo.
For most C ecosystem stuff you can try overriding the version, but you'll quickly notice why this is a hard problem: Different software versions want to be built in different ways! Someone would have to therefore maintain the quirks of each package version's build process for each package for all eternity, an insanely huge endeavor.
Also, even if it were possible this would break the Nix binary cache model, because suddenly you'd have an insane combinatorial explosion of not just package versions, but also versions of their dependencies. In order to preserve purity and reproducibility, a change in dependency version means that all dependents have to be rebuilt, taking up insane amounts of CPU and storage on the build farm.
I don't think that your request is unreasonable (I'd love to have this feature!), but it's probably not fully possible in any software distribution ecosystem.
So your remark that nix is lacking in dependency management is quite far from the truth - it is the only proper solution to the dependency hell problem I’ve seen (of course as well as guix which employs the same model)
To be clear, i'm on NixOS and i use Flakes to manage my imports.
Letting go of versioning feels like nonsense. I need to write my software against specific versions of other libraries. I can't just ignore version and hope for the best.
Why does Nix think suddenly Semver compatibility is no longer a concern?