| 22 Apr 2025 |
 flokli | This is the dependencies / devDependencies problem, and whether to transitively propagate dev dependencies inputs | 10:06:56 |
| flokli | I'm not sure there's been some scoping out around this yet, but it's one of the issues with the current design. | 10:13:23 |
 sterni (he/him) | Any ideas what change this could be related to? Is this a bug or where there conscious changes to restrict-eval? I looked at the changelogs but nothing jumped out to me (maybe the relative flake change?) https://github.com/NixOS/nixpkgs/issues/400784 | 10:15:13 |
 dramforever | can you try nix-shell -i bash -p coreutils jq nix -I nixpkgs=.? | 10:59:59 |
| dramforever | * can you try nix-shell -p coreutils jq nix -I nixpkgs=.? | 11:00:16 |
| dramforever | sorry, edited | 11:00:21 |
| sterni (he/him) | sure, that works fine | 11:01:17 |
| dramforever | and then also bash {that script} | 11:01:22 |
| dramforever | but with the dependencies in $PATH | 11:01:35 |
| dramforever | in like nix shell or something | 11:02:27 |
| dramforever | well, it's supposed to fail pretty fast right? if so i can't reproduce this problem | 11:04:14 |
| dramforever | i'm on aca270648eca which is latest master of writing | 11:06:18 |
| sterni (he/him) | hmm I can with nix-instantiate --eval --option restrict-eval true -I . ./maintainers/scripts/haskell/transitive-broken-packages.nix on current master | 11:08:40 |
| sterni (he/him) | it's possible that it's because of a daemon / frontend version mismatch then | 11:09:10 |
| dramforever | it hasn't finished but it's doing something for me and hasn't failed yet | 11:09:26 |
| sterni (he/him) | then it works :) | 11:09:35 |
| sterni (he/him) | I'll ask the other Haskell ppl if no one else can repro it, it doesn't matter probably the daemon | 11:10:03 |
| dramforever | maybe there's some funny impurities? | 11:11:06 |
| dramforever | what's your nixpkgs commit, and what does which nix say? | 11:16:31 |
 jaen | In reply to @flokli:matrix.org
This is the dependencies / devDependencies problem, and whether to transitively propagate dev dependencies inputs Yes, but my understanding was you can work around this somewhat with flakes (either using getFlake one of the various flake-compats or https://flake.parts/options/flake-parts-partitions.html) - so my point there was that with automatic hosting as described with those "crystals", you would lose option to use those workarounds until a proper concept of "scoped" inputs is added. Unless I misunderstood how those workarounds work exactly and they don't really allow you to fetch those dev inputs lazily. Hope it's more clear now what I wanted to say? | 11:34:35 |
| flokli | In reply to @jaen:matrix.org
Yes, but my understanding was you can work around this somewhat with flakes (either using getFlake one of the various flake-compats or https://flake.parts/options/flake-parts-partitions.html) - so my point there was that with automatic hosting as described with those "crystals", you would lose option to use those workarounds until a proper concept of "scoped" inputs is added. Unless I misunderstood how those workarounds work exactly and they don't really allow you to fetch those dev inputs lazily. Hope it's more clear now what I wanted to say? You can use various hacks to workaround various problems, yes. But the way I understood it was that "crystals", or however we want to call a new schema / layout aim to solve this as a first-class citizen, not just another workaround. | 11:37:31 |
| flokli | There's too many workarounds for problems with the schema. | 11:37:52 |
| jaen | Yeah, that's true. I've just meant that "crystals" would have to come with input scopes from the get go, as it would make those workarounds (such as they are) not viable. | 11:39:52 |
| flokli | I'd be happy to read and give feedback on a design proposal. | 11:41:15 |
 Find me at aleksana:qaq.li | Idea: We should detect a "minimum syscall permission set" that allows Nix to work and make both hydra and ofborg follow this specification. Currently nested containers (for example, nix-build in systemd-nspawn) cannot pass the checkPhase of some packages, but we don't fix it because CI isn't set up as such. | 12:55:28 |
 Martin Schwaighofer | In reply to @puck:puck.moe
most of the logic in that file is to properly adjust stringLength output to the post-substitution paths, even, the actual logic there is like three lines Just asking out of curiosity: Why was string length important to you?
I don't see when that would matter with how they are usually used, so I figure maybe you are doing something unusual. 😅 | 15:21:26 |
|  Thomas joined the room. | 17:11:37 |
|  griff joined the room. | 19:07:55 |
| 23 Apr 2025 |
|  @slamphear:matrix.org joined the room. | 00:07:12 |
 puck | In reply to @mschwaig:matrix.org
Just asking out of curiosity: Why was string length important to you?
I don't see when that would matter with how they are usually used, so I figure maybe you are doing something unusual. 😅 it's for calculating the length of the final string, post-substitution, so it can be properly seated into the tarball | 12:39:20 |
