| 23 Jul 2022 |
 growpotkin1 | Yeah that's pretty intuitive.
It reminds me a little bit of `scopedImport` but presumably less ugly | 21:45:50 |
| growpotkin1 | Scoped important was so close to being awesome. It's heartbreaking 😂 | 21:46:29 |
| growpotkin1 | * Scoped import was so close to being awesome. It's heartbreaking 😂 | 21:46:37 |
 tomberek | This approach also goes along with the thought that these objects that are called with callPackage - i've used the term protoDerivations or blueprints - allow for easier composition and re-use than turning them into packages with makeOverridable and then trying to "overrideAttrs" your way to success. So i'd say that late-calling callPackage gives us easier UX. | 21:49:05 |
| growpotkin1 | You got sources I can take for a spin? | 21:50:15 |
| growpotkin1 | This sounds like my 3rd layer that generates builders from meta | 21:50:56 |
| growpotkin1 | This is an example of building layers 2-4. The commented blocks use an older extension object and I'm still migrating them but you'll get the idea.
https://github.com/aameen-tulip/at-node-nix/blob/nps-scoped/pkgs/node-pkg-set.nix | 21:53:14 |
| tomberek | not yet, but we do seem to be playing in a similar design space. Let me clean things up. Not sure if this is applicable to Nixpkgs design, but might help inform it. | 22:01:25 |
| growpotkin1 | Yeah keep in touch. And of course, feel free to expropriate patterns from my libs 🙂
I think exploring this sort of thing may be good for test driving routines that can work their way into Nixpkgs after a bit of battle testing | 22:20:53 |
| 26 Jul 2022 |
| growpotkin1 | Alright. My Frankenstein's monster is alive working with my over-engineered overlay system.
I won't pretend that it's "a good model" as is; but it's able to back propagate changes to higher scopes, sort of like a module system does.
Its probably misguided, but 🤷 | 02:10:39 |
| growpotkin1 | Now if only I could understand "why my code works" I'd be golden | 02:14:15 |
| growpotkin1 | https://github.com/aameen-tulip/at-node-nix/blob/nps-scoped/pkgs/node-pkg-set.nix
You can feed it whatever node.js garbage you have laying around, and it should give you the same derivation without regard for what "method of input" you gave.
This means if I use pkg A-1.0.0 in one lock or I pull it from a registry or I have a local copy or whatever - cache hits work.
This is the biggest issue with node2nix now - it can't "really" compose node package sets which is why Nixpkgs has to maintain a single instance and they don't recommend packaging modules as separate from CLI tools.
Oh, and I don't call NPM ever and Python only gets used when it's actually needed. Most derivations don't depend on Node even so you won't hog hydra. | 02:21:02 |
| 27 Jul 2022 |
 mkaito | I have to skip today's call, but I'll check the notes afterwards. | 14:44:35 |
 infinisil | We're having the call now at https://meet.jit.si/nixpkgs-architecture | 15:01:59 |
 yorik.sar | I'll skip today as well. | 15:02:43 |
| infinisil | https://pad.lassul.us/uIi7xeSJTW6LJUEHulZgVQ | 15:03:37 |
| infinisil | Thanks for participating everybody, I think this was a good discussion, let's look at the mkDerivation redesign prototypes [until] next time | 16:02:41 |
| infinisil | Oh I'm just noticing that me typing the meeting notes seems to be audible 😅 | 16:17:53 |
 DavHau | Related to the discussion today. Here my rant about buildHooks + discussions in discourse (more than one year old): https://discourse.nixos.org/t/are-hooks-abused-as-a-module-system-for-nix-builds/13107 | 16:22:02 |
| infinisil | Hey, Robert Hensing (roberth) gave me some feedback regarding these meetings, that they might be going too much into technical details which would be better discussed asynchronously. We talked about how it might be better for these meetings to be more of a standup since last week and planning for the next week, only going into more details if there's time left. | 18:18:11 |
| infinisil | I think that would be a good idea, what do other people here think of this? I personally like just discussing technical details for an hour, but it's probably not the best for efficiency of this teams goals | 18:19:09 |
 Winter (she/her) | I've not been able to attend meetings thus far, so excuse my ignorance. But how much time has gone into discussing technical details, and has this ever resulted in running out of time to discuss the entire agenda? | 18:20:23 |
 Alyssa Ross | I probably wouldn't attend standup-style meetings, as I don't think there would be much interesting for me there | 18:21:11 |
| infinisil | Alyssa Ross: I'd probably argue for a mix, where e.g. the first 10 minutes it could be a standup, then 10 minutes of planning for the next week, who wants to/has time to work on what, then technical discussions or quick feedback rounds | 18:25:38 |
| infinisil | Winter (she/her): It's mostly been technical details thus far, we haven't discussed the overall agenda a lot | 18:26:41 |
| infinisil | An alternative is to have two meetings: A short one for standup and planning, and a long open-ended one for technical discussions | 18:32:41 |
| infinisil | And of course one can also have arbitrarily many discussions throughout the week, e.g. like I had with John Ericson and others last Friday | 18:35:36 |
| 28 Jul 2022 |
|  danielrf joined the room. | 03:10:50 |
 Sandro | In reply to @infinisil:matrix.org
An alternative is to have two meetings: A short one for standup and planning, and a long open-ended one for technical discussions Or do the short part first and then change into the open ending part | 09:18:40 |
| 29 Jul 2022 |
| infinisil | Alyssa Ross: What was that scripting-like process-based thing called again? It's very minimal but allows you to do various things based on some simple executables you chain together | 15:33:42 |
