| 21 Apr 2025 |
 Las | this is cursed | 17:46:42 |
 puck | ^_^ | 19:14:37 |
| puck | 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 | 19:18:01 |
| 22 Apr 2025 |
 jaen | In reply to @tomberek:matrix.org
I have explored a concept before where a flake could be composed of multiple sub-components that had inter-related inputs. It is different from what are normally called sub-flakes, but I think is closer to what people are expecting them to be. I called it "crystals" and the initial proof-of-concept was a relatively simple matter of searching through a source tree for all crystal.nix files and merging their inputs into the root's lockfile: https://github.com/flox/nix/commit/8a684bdee6009e6375e855ed79bb9c532dae805c . Interesting, but I think this loses the useful property of scoping inputs to some subflake, such as development inputs. For this to be equivalent, I think it would have to have some concept of development (name to be biskeshed) inputs that are only fetched if actually used (e.g. a devshell using them is entered or something). Not sure how much more complex this would have made the implementation. | 07:01:37 |
 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 | 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 | 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 | 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 | 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 | then it works :) | 11:09:35 |
| sterni | 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 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | 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 |
