| 20 Jul 2022 |
 problems | https://github.com/SwadicalRag/wasm2lua | 16:24:48 |
| problems | a bit silly but could be considered for portability if we end up on wasm | 16:25:16 |
|  John Ericson joined the room. | 16:44:56 |
 Gytis Ivaskevicius | 
Download image.png | 16:51:43 |
| Gytis Ivaskevicius | Welp, good news everyone!!
I had a chat with John and he will join us on the next call and if we are lucky may become an advisor/mentor of sorts for this particular issue | 16:51:43 |
| Gytis Ivaskevicius | * Welp, good news everyone!!
I had a chat with John and he will join us on the next call and if we are lucky may become an advisor/mentor for this particular issue | 16:51:59 |
 infinisil | Awesome! Glad to have you John Ericson ! | 16:56:39 |
| John Ericson | glad to be here! | 16:56:56 |
| infinisil | Meanwhile I uploaded the meeting notes to https://github.com/nixpkgs-architecture/meetings/blob/master/2022-07-20.md, which also contains the link to the recording | 16:56:56 |
| John Ericson | lots to talk about, but a shorter term task I hope to get people to help me with is repackaging compiler with upstream yak shaves | 16:57:33 |
| John Ericson | it's hard, but it untangles lots of things which in turn allows other architectural efforts to procede | 16:57:55 |
| infinisil | It's a bit tricky because everybody probably has their own priority of issues, but if it's a dependency for other issues then it might be very worthwhile | 16:59:20 |
| infinisil | Gotta work from the bottom up, can't have a loose foundation | 16:59:37 |
| infinisil | John Ericson: Do you think making stdenv a bit more independent of nixpkgs would be a good idea? This could include things like it having its own repository, its own release cycle, it having its own nixpkgs-independent basic builders, etc. | 17:02:41 |
| infinisil | Own Hydra jobset | 17:02:56 |
| John Ericson | infinisil: I worry more repos will make cross-cutting refactors harder | 17:03:26 |
| John Ericson | I hope we can get types before such experiments | 17:03:38 |
| John Ericson | types would offset that downside a lot | 17:03:44 |
| infinisil | If not a separate repo, it could also live independently in a subtree, a bit like nixpkgs lib | 17:04:12 |
| infinisil | I'm imagining a stricter dependency chain of pkgs depending on stdenv, but not the other way around | 17:04:49 |
| infinisil | The question of splitting nixpkgs should also be discussed though. Having a stricter interface for its parts and more backwards compatibility guarantees goes into this | 17:06:08 |
| John Ericson | I do like how legacy stdenv moves us towards maybe not having a single stdenv at all | 17:09:57 |
| John Ericson | ultimately it's good to package things at a higher level | 17:10:15 |
| John Ericson | (though polyglot projects are always a thorn in such efforts) | 17:10:30 |
| problems | making stdenvs composable might be a good thing then? | 17:11:56 |
| John Ericson | perhaps, like sander's thing, but I might prefer to think stdenvs as more the results of composition than the things which are composed | 17:15:58 |
| infinisil | John Ericson: Ah so like, here's how to get bootstrap glibc, here's how to bootstrap curl, do both at once? | 17:17:31 |
| John Ericson | also stdenv != bootstrapping | 17:18:07 |
| infinisil | Please elaborate! | 17:18:21 |
| John Ericson | I meant to rearrange the files to reflect this | 17:18:21 |
