| 30 Jan 2023 |
 infinisil | I archived https://github.com/nixpkgs-architecture/simple-package-paths because it would get confusing to get feedback in multiple places and have multiple repositories | 19:06:00 |
| 31 Jan 2023 |
|  @blaggacao:matrix.org joined the room. | 03:47:02 |
| 3 Feb 2023 |
| @blaggacao:matrix.org | Potential motivation (coutesy of eliminated guesswork):
Scriptable package scraping with e.g. https://discourse.nixos.org/t/nix-init-generate-nix-packages-from-urls-with-hash-prefetching-dependency-inference-license-detection-and-more/25035 | 03:12:11 |
| @blaggacao:matrix.org | Don't want to put that one the PR (and increase the noise, there). Just add it if you feel like ... | 03:12:49 |
| @blaggacao:matrix.org | * Potential additional motivation (coutesy of eliminated guesswork):
Scriptable package scraping with e.g. https://discourse.nixos.org/t/nix-init-generate-nix-packages-from-urls-with-hash-prefetching-dependency-inference-license-detection-and-more/25035 | 03:13:18 |
|  figsoda joined the room. | 04:28:38 |
| figsoda | In reply to @blaggacao:matrix.org
Potential additional motivation (coutesy of eliminated guesswork):
Scriptable package scraping with e.g. https://discourse.nixos.org/t/nix-init-generate-nix-packages-from-urls-with-hash-prefetching-dependency-inference-license-detection-and-more/25035 I was actually looking for this RFC (not created yet at the time) when I was replying to one of the replies in the thread. just happened to look at the rfcs and found this rfc, nice to see you here again | 04:44:52 |
| @blaggacao:matrix.org | I wanted to make a script to scrape all mdbook- preprocessors once and for all. But I thought I'd better wait for after this PR. | 04:46:23 |
| @blaggacao:matrix.org | * I wanted to make a script to scrape all mdbook- preprocessors once and for all. But I thought I'd better wait for after this RFC landed. | 04:46:37 |
| 5 Feb 2023 |
 growpotkin1 | Does repology count JS modules as packages? | 03:43:50 |
| growpotkin1 | I think my JS+Nix stuff is ready for use in Nixpkgs if there were any interest in replacing the node2nix infrastructure.
Surprisingly the load on CI is relatively low. I knocked out 18,000 packages from a cold cache in 1.5 hours with a single GitHub box.
The majority of builds run with only jq and stdenv. node is only a dependency for <1% of them. In terms of limiting load on hydra this is an important selling point. | 03:54:03 |
 Winter (she/her) | In reply to@growpotkin1:matrix.org
I think my JS+Nix stuff is ready for use in Nixpkgs if there were any interest in replacing the node2nix infrastructure.
Surprisingly the load on CI is relatively low. I knocked out 18,000 packages from a cold cache in 1.5 hours with a single GitHub box.
The majority of builds run with only jq and stdenv. node is only a dependency for <1% of them. In terms of limiting load on hydra this is an important selling point. I think my JS+Nix stuff is ready for use in Nixpkgs if there were any interest in replacing the node2nix infrastructure.
I have an in-progress migration roadmap thing to move to buildNpmPackage and buildYarnPackage, so yeah, there's interest. | 05:17:19 |
| growpotkin1 | Sweet. Honestly I worked my ass off on this, I'm excited to get it out there.
I've got npm and yarn v2/3 translation covered already, so this might be a good fit for the migration work | 05:20:33 |
| Winter (she/her) | not sure how I feel about having two more or less competing JS build support systems in-tree... | 05:22:31 |
| Winter (she/her) | note that I'm biased, as I've worked on my stuff for quite a while as well (and it's already in-tree). | 05:23:22 |
| Winter (she/her) | * note that I'm biased, as I've worked on my stuff for quite a while too (and it's already in-tree). | 05:23:37 |
| growpotkin1 | Oh I misunderstood your first message. | 05:23:50 |
| growpotkin1 | No sweat then. I don't want to step on any toes. | 05:24:11 |
| Winter (she/her) | There are definitely merits to your approach, though I believe there are may also be downsides. | 05:24:39 |
| Winter (she/her) | Happy to talk with you further on this, though maybe not tonight -- it's late. | 05:24:55 |
| infinisil | growpotkin ( Alex Ameen ): I'd really like to see some stats, comparing the current approach, Winter's approach and yours. Should include eval time, build time, lines of code. Also comparing features between the three | 09:51:28 |
| infinisil | Also I think before it could be upstreamed, your tooling should be field tested by widely announcing it and having people try it | 09:52:37 |
| @blaggacao:matrix.org | To clone your limited capacity while maintaining the legitimacy and momentum, the NAT may consider establishment of chapters to parallelize parallelizables. | 17:53:11 |
| @blaggacao:matrix.org | * To clone your limited capacity while maintaining the legitimacy and momentum, the NAT may consider establishment of chapters to parallelize work on parallelizable improvments. | 17:53:29 |
| @blaggacao:matrix.org | One such that just came to my mind while seeing this issue and this workaround would be a Fetcher Chapter and maybe a Package Chapter. | 17:54:44 |
 tomberek | At the moment we’ve been trying to focus on a single project at a time. Historically, trying to do multiple things at once led to stagnation. | 17:54:49 |
| tomberek | But general work on Nixpkgs can of course be done in parallel. | 17:55:18 |
| @blaggacao:matrix.org | That may be true, but creating delegation slots for someone to be invited to step up doesn't seem like a risk. | 17:55:29 |
| @blaggacao:matrix.org | * That may be true, but creating delegation slots for someone to be invited to step up doesn't seem like an a-priori risk. | 17:55:41 |
| @blaggacao:matrix.org | A little bit of push, to see if there is contributor market pull to organize around these topics while under the legitimacy and authority support of the NAT. | 17:56:42 |
