| 19 Feb 2025 |
 emily | as in, what allowSubstitutes is meant to do doesn't help solve the problem in question in any way, and what it's meant to do has largely (on the Nix side at least) turned out to hurt more than it helps | 03:22:14 |
| emily | (I'd be hesitant to have CI build stuff that's considered legally problematic enough to not be distributable in the first place, but I guess Guix is strict enough about licensing that something like zfs.ko is probably the limit of the risk there.) | 03:23:28 |
 mra | In reply to @emilazy:matrix.org
as in, what allowSubstitutes is meant to do doesn't help solve the problem in question in any way, and what it's meant to do has largely (on the Nix side at least) turned out to hurt more than it helps one question: another use of allowSubstitutes = 0 on Guix is for HPC packages, specifically those which have CPU-specific optimisations, so that a client doesn't substitute a package which is optimised for a different CPU. How does Nix handle this case? | 06:54:40 |
| mra | This is somewhat orthogonal to the distributability concern, I agree, but this is currently one of the main applications of non-substitutability for us. | 06:55:50 |
 Eli Kogan-Wang | In reply to @morgan.arnold:matrix.org
one question: another use of allowSubstitutes = 0 on Guix is for HPC packages, specifically those which have CPU-specific optimisations, so that a client doesn't substitute a package which is optimised for a different CPU. How does Nix handle this case? Are you asking about https://wiki.nixos.org/wiki/Build_flags?
See https://github.com/NixOS/nixpkgs/pull/202526#issue-1461820752 | 07:21:01 |
| mra | Oh, interesting. It just has to be specifically requested. That makes sense. | 07:30:28 |
| emily | In reply to @morgan.arnold:matrix.org
one question: another use of allowSubstitutes = 0 on Guix is for HPC packages, specifically those which have CPU-specific optimisations, so that a client doesn't substitute a package which is optimised for a different CPU. How does Nix handle this case? I don't understand how this would ever arise. different flags would mean different derivation hashes so you'd never get an incorrect substitution, right? | 14:12:12 |
| emily | if you mean using -march=native to get an impure build, I'd suggest just not doing that. it's cheap to specify the relevant platform explicitly and fixes the determinism issue | 14:12:57 |
| emily | FYI, the 2.26 update breaks buildInputs = [ nixVersions.nix_2_26 ]; | 23:03:20 |
| emily | it has .dev and .libs (should be .lib?) attributes in passthru, but those are not proper outputs | 23:03:41 |
| emily | uh, and .dev is just … empty | 23:04:21 |
| emily | ok I guess you have to use .dev.dev. anyway this is very weird and breaking. | 23:05:16 |
 ElvishJerricco | emily: yes, 2.26 is now componentized and the nix_2_26 build is basically just a symlink farm of all the components | 23:27:18 |
| ElvishJerricco | you have to depend on the specific libs you need via the libs passthru I think | 23:27:53 |
 roberth | working on it | 23:28:09 |
| ElvishJerricco | Robert Hensing (roberth): Does nixpkgs actually benefit from this style of packaging for Nix? I can see the utility while iterating on Nix, but I'm not sure componentized builds are actually benefiting any users or applications in nixpkgs, and it breaks a lot of norms | 23:29:22 |
| ElvishJerricco | I'm open to it; but I'm interested in the use case | 23:30:17 |
| roberth | I'll refer to here https://github.com/NixOS/nix/issues/12472#issuecomment-2662973140 | 23:31:10 |
| roberth | another small benefit I forgot is that this way we don't have to install the C API libraries | 23:32:24 |
| roberth | but the main motivations are in that thread | 23:32:36 |
| emily | fwiw, I don't think passthru.dev can really work fundamentally even if the .dev.dev thing was fixed, there are too many assumptions about things being actual outputs | 23:32:44 |
| emily | (while I'm here, is the nix/config.h header deprecated?) | 23:33:11 |
| roberth | I have some code that seems to implement the multi output attribute interface correctly now | 23:33:31 |
| roberth | I think so | 23:34:40 |
| emily | fwiw I think the "import the nix/ directory of the Nix repo" approach makes it much harder for regular Nixpkgs contributors to fix issues in the Nix packaging, since there is an entire layer of non-standard abstractions that mostly do not directly benefit Nixpkgs and diverge from its conventions; there's a reason we usually don't import other projects' Nix infrastructure wholesale when packaging them | 23:39:58 |
| emily | but my primary concern is just that currently it seems to break every downstream that uses Nix as a library | 23:40:17 |
| ElvishJerricco | I'm also still just not really seeing the actual use case... | 23:40:39 |
| emily | uh, also the components use lib.fileset somehow? | 23:42:58 |
| emily | which isn't meant to be allowed in Nixpkgs and I don't really understand how it's not breaking eval | 23:42:59 |
| emily | oh, I guess because it's dead code in the Nixpkgs context | 23:43:29 |
