| 23 Sep 2025 |
 Albert Larsan | One thing to try is to use NPM's package.json, but the repo's sources (then it may work) | 18:16:08 |
| 26 Sep 2025 |
|  @acidbong:envs.net left the room. | 03:21:33 |
| 29 Sep 2025 |
 Emma [it/its] | Q: is there a way to make buildNpmPackage split up dependency fetches into separate drvs? | 23:42:45 |
| Emma [it/its] | i guess that'd add evaluator overhead, but would help a lot with all the redownloading when iterating over builds with minor package set changes | 23:43:59 |
| Emma [it/its] | in related news: any idea why, when i build my package with nix, it fails to start saying it's missing a module? | 23:45:33 |
| 30 Sep 2025 |
 dish [Fox/It/She] | nope | 00:04:52 |
| Emma [it/its] | ouch | 00:05:36 |
| dish [Fox/It/She] | thats a feature of some other builders but atm buildNpmPackage doesn't have that | 00:09:36 |
| dish [Fox/It/She] | iirc the yarn fetcher does though | 00:09:42 |
 Charles | my understanding is that builders in nixpkgs don't really care about granularity like this because in nixpkgs' case it often would need to rebuild everything anyway | 00:13:57 |
| Charles | * my understanding is that builders in nixpkgs don't really care about granularity like this in general because in nixpkgs' case it often would need to rebuild everything anyway | 00:14:06 |
| dish [Fox/It/She] | there's that yes | 00:15:22 |
| dish [Fox/It/She] | ideally with CA derivations we could just download the package once and be done with it | 00:15:37 |
| dish [Fox/It/She] | but CA derivations are far-term to never at this point so | 00:15:48 |
| dish [Fox/It/She] | with CA derivations that kind of granularity would actually be a good idea to have, since they could more easily be de-duplicated and re-used even if npm/node versions changed | 00:16:37 |
| dish [Fox/It/She] | * with CA derivations that kind of granularity would actually be a good thing to have, since they could more easily be de-duplicated and re-used even if npm/node versions changed | 00:16:42 |
| Emma [it/its] | well, youre building a local cache for it to use anyways, no?
i'd assume the tarballs wouldnt change? | 00:18:25 |
| Emma [it/its] | hm, is there some way to override dependencies with buildNpmPackage? | 00:19:34 |
| Emma [it/its] | say ie. i want to add a feature flag to my nix package for email support, or postgres support | 00:19:48 |
 Winter | what do you mean override? it sounds you’re specifically meaning it in the sense of adding or removing dependencies? | 01:02:25 |
| Emma [it/its] | yes | 01:03:07 |
| Emma [it/its] | probably the biggest offender in my case is ommitting @aws-sdk/client-s3 for the majority of users that dont care about s3 support lol | 02:01:09 |
| Emma [it/its] | additional question: is there any reason a buildNpmPackage result has an explicit dependency on ${NODEJS}-sources? | 03:09:14 |
| Winter | (i’ll try and remember to respond to all of these tomorrow, going to bed; but rapid fire: just removing the directories but keeping the same lockfile would be good, and no; i just haven’t fixed it yet) | 04:04:34 |
| Emma [it/its] | ah i see, thanks for the responses Winter!
good night :) | 04:06:46 |
 Cobalt | Doesn't importNpmLock do this though? Iirc in build logs it does them on at a tims | 04:12:19 |
| Emma [it/its] | are they separate derivations though? or is it jut the standard npm logging when it fetches them | 04:20:53 |
| Cobalt | It appears so, tree from one of the packages, https://git.cobalt.rocks/-/snippets/32. At least the sources appear to be on drv each
(Eval time is a bit higher because of this but it helps with dedup). | 13:31:06 |
| Cobalt | * It appears so, tree from one of the packages, https://git.cobalt.rocks/-/snippets/32. At least the sources for npm deps appear to be on drv each
(Eval time is a bit higher because of this but it helps with dedup). | 13:31:12 |
|  NixOS Moderation Bot banned  @joepie91:pixie.town (divsive behavior). | 19:23:48 |
