4 ms·

How does default.nix handle dependencies? From what i've (i'm on NixOS) seen you just see something like `gcc` or `openssl`, with no clue what version. Tbh i'v

How does default.nix handle dependencies? From what i've (i'm on NixOS) seen you just see something like `gcc` or `openssl`, with no clue what version. 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.

kfajdsl 5y ago
The way I currently pin packages is to just import a specific commit hash of nixpkgs as a variable. Niv[0] is a tool that makes doing that and updating very painless. [0]: https://github.com/nmattia/niv https://github.com/nmattia/niv
- adkadskhj 5y ago
  But you still have to look up the individual values right? I'm using Flakes, pinning commit hashes is automatic (lockfile) - but i still have no clue what version any package is on. 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.
  - casept 5y ago
    For languages with relatively uniform package ecosystems (like Rust and Go) there are tools that can generate Nix code for you from lockfiles with exact versions. In practice this usually suffices, because these ecosystems also have to remain compatible with other environments where OS-provided dependencies like C compilers and libs have wildly differing versions. 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.
kaba0 5y ago
`gcc` is basically a function/package derivation. What it evaluates to depends on the given channel/nixpkgs source you use - in the derivation (something like development/../gcc/default.nix) you will find the exact commit/version that will be used. For packages that routinely use multiple versions something like python2 and python3 are both available but the whole point of nix is to let go of this notion of versioning — you can reference out of tree packages as well, hell you can even use Y compiled with gcc and clang and reference them both. 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)
- adkadskhj 5y ago
  > both available but the whole point of nix is to let go of this notion of versioning 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?

kfajdsl 5y ago

The way I currently pin packages is to just import a specific commit hash of nixpkgs as a variable. Niv[0] is a tool that makes doing that and updating very painless. [0]: https://github.com/nmattia/niv https://github.com/nmattia/niv

adkadskhj 5y ago
But you still have to look up the individual values right? I'm using Flakes, pinning commit hashes is automatic (lockfile) - but i still have no clue what version any package is on. 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.
- casept 5y ago
  For languages with relatively uniform package ecosystems (like Rust and Go) there are tools that can generate Nix code for you from lockfiles with exact versions. In practice this usually suffices, because these ecosystems also have to remain compatible with other environments where OS-provided dependencies like C compilers and libs have wildly differing versions. 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.

kaba0 5y ago

`gcc` is basically a function/package derivation. What it evaluates to depends on the given channel/nixpkgs source you use - in the derivation (something like development/../gcc/default.nix) you will find the exact commit/version that will be used. For packages that routinely use multiple versions something like python2 and python3 are both available but the whole point of nix is to let go of this notion of versioning — you can reference out of tree packages as well, hell you can even use Y compiled with gcc and clang and reference them both. 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)

adkadskhj 5y ago
> both available but the whole point of nix is to let go of this notion of versioning 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?