4 ms·

As I understand it, flakes don't really solve the problem parent is talking about. The discoverability is still poor. Say I need a python package at version x.x

As I understand it, flakes don't really solve the problem parent is talking about. The discoverability is still poor. Say I need a python package at version x.x.x. How do I find which nixpkgs commit hash I should use to get that specific version?

scintill76 5y ago
I believe you can override the version property of the derivation that builds the package, if its build script is compatible enough between the two versions.
nh2 5y ago
> How do I find which nixpkgs commit hash I should use to get that specific version This is answered in a sibling comment here: https://news.ycombinator.com/item?id=28243409 https://news.ycombinator.com/item?id=28243409 The tool does exactly that. However: > find and use specific versions of a dependency in, you know, applications. This is not what nixpkgs currently provides, or aims to provide. nixpkgs is like the Debian, Gentoo, etc. package repos: In most cases, it provides one version of a package. If you want to use an older one, you have to use older version of all dependent packages, as they were at that time; this in practice means using software with security vulnerabilities that are only fixed in current nixpkgs. nixpkgs is not currently designed to let you compose your application from libraries taken from different nixpkgs versions. It is insecure (see above) and slow (evaluating more than a few different nixpkgs versions takes a long time). The current correct way is to use a current nixpkgs version as a base, and then use an override to update the sources of the packages you want to have a different version of explicitly. Or use a tool that does this automatically for your programming ecosystem based on that one's package manager, like `stack2nix` for Haskell, `yarn2nix` for Javascript, and so on. Nixpkgs makes such overrides easy.
- dmitriid 5y ago
  What you describe is weird. It's very common to pin dependencies to specific versions. And upgrade them carefully, also to specific versions. If I use a dependency at version X.Y, a vulnerability is discovered in it, and fixed in version X.Y.Z, I don't want to "start from base nixpkgs". I want to upgrade that specific dependency to a very specific version. From how you described it, it's either not possible or extremely cumbersome to do with nix. Which begs the question: what's the point?
  - nh2 5y ago
    > I want to upgrade that specific dependency to a very specific version. Yes, this is what I am arguing you should do, by overriding its source to that version (which I described as being easy). You should not try to pull in a version of nixpkgs (whole OS) that has X.Y.Z, and combine it with another version of nixpkgs (whole OS) that has some other library's version A.B.C. In the same way as you don't try to combine 3 different versions of Debian to get specific versions of 3 different Python libraries. Concrete example: Current nixpkgs has libpng-1.3 and libjpeg-4.6. For building your app you desire libpng-1.2.3 and libjpeg-4.5.6. To get them, you use the current nixpkgs, and override `libpng` and `libjpeg` to the versions you want using e.g. `libpng.override { src = fetchGit ... }`. You do NOT do `libpng = (import <older-nixpkgs-version-1> {})` and `libjpeg = (import <older-nixpkgs-version-2> {})`. Because that way you will also end up with 3 different versions of e.g. `glibc`, which may be incompatible. I hope this clarifies it!
    - ducktective 5y ago
      We need to specify hashes for `libpng-1.3` and `libjpeg-4.6` right? Is there tooling to fill-out them automatically? How to find out what versions of `libpng` are available to be used in `shell.nix` or `shell.flake` with nix tools?

scintill76 5y ago

I believe you can override the version property of the derivation that builds the package, if its build script is compatible enough between the two versions.

nh2 5y ago

> How do I find which nixpkgs commit hash I should use to get that specific version This is answered in a sibling comment here: https://news.ycombinator.com/item?id=28243409 https://news.ycombinator.com/item?id=28243409 The tool does exactly that. However: > find and use specific versions of a dependency in, you know, applications. This is not what nixpkgs currently provides, or aims to provide. nixpkgs is like the Debian, Gentoo, etc. package repos: In most cases, it provides one version of a package. If you want to use an older one, you have to use older version of all dependent packages, as they were at that time; this in practice means using software with security vulnerabilities that are only fixed in current nixpkgs. nixpkgs is not currently designed to let you compose your application from libraries taken from different nixpkgs versions. It is insecure (see above) and slow (evaluating more than a few different nixpkgs versions takes a long time). The current correct way is to use a current nixpkgs version as a base, and then use an override to update the sources of the packages you want to have a different version of explicitly. Or use a tool that does this automatically for your programming ecosystem based on that one's package manager, like `stack2nix` for Haskell, `yarn2nix` for Javascript, and so on. Nixpkgs makes such overrides easy.

dmitriid 5y ago
What you describe is weird. It's very common to pin dependencies to specific versions. And upgrade them carefully, also to specific versions. If I use a dependency at version X.Y, a vulnerability is discovered in it, and fixed in version X.Y.Z, I don't want to "start from base nixpkgs". I want to upgrade that specific dependency to a very specific version. From how you described it, it's either not possible or extremely cumbersome to do with nix. Which begs the question: what's the point?
- nh2 5y ago
  > I want to upgrade that specific dependency to a very specific version. Yes, this is what I am arguing you should do, by overriding its source to that version (which I described as being easy). You should not try to pull in a version of nixpkgs (whole OS) that has X.Y.Z, and combine it with another version of nixpkgs (whole OS) that has some other library's version A.B.C. In the same way as you don't try to combine 3 different versions of Debian to get specific versions of 3 different Python libraries. Concrete example: Current nixpkgs has libpng-1.3 and libjpeg-4.6. For building your app you desire libpng-1.2.3 and libjpeg-4.5.6. To get them, you use the current nixpkgs, and override `libpng` and `libjpeg` to the versions you want using e.g. `libpng.override { src = fetchGit ... }`. You do NOT do `libpng = (import <older-nixpkgs-version-1> {})` and `libjpeg = (import <older-nixpkgs-version-2> {})`. Because that way you will also end up with 3 different versions of e.g. `glibc`, which may be incompatible. I hope this clarifies it!
  - ducktective 5y ago
    We need to specify hashes for `libpng-1.3` and `libjpeg-4.6` right? Is there tooling to fill-out them automatically? How to find out what versions of `libpng` are available to be used in `shell.nix` or `shell.flake` with nix tools?