Nix NodeJS | 208 Members | |
| 59 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Nov 2023 | ||
| turning off parallelism shouldn't ever help with anything but making the logs more coherent unless your internet link gets spooked by the concurrent connections to the same domain. but even then the retry backoff logic bacisally means they will eventually be tried one at a time if that causes problems noe | 16:50:59 | |
| * turning off parallelism shouldn't ever help with anything but making the logs more coherent unless your internet link gets spooked by the concurrent connections to the same domain. but even then the retry backoff logic bacisally means they will eventually be tried one at a time if that causes problems now | 16:51:02 | |
| * turning off parallelism shouldn't ever help with anything but making the logs more coherent unless your internet link gets spooked by the concurrent connections to the same domain. but even then the retry backoff logic basically means they will eventually be tried one at a time if that causes problems now | 16:51:17 | |
| 13 Nov 2023 | ||
| I try to build a small package.json with buildNpmPackage. I seem to deterministically (repeatdly) hit:
while | 16:57:15 | |
In reply to @keiichi:matrix.orgPrefetching that URL has nothing to do with npm trying to do something it shouldn't in the nix sandbox. Can you share the full lock and the package-lock.json file you are using? | 16:59:01 | |
(ENOTCACHED should really be renamed to ENPMDIDABADTHINGAGAIN) | 16:59:28 | |
| sure, where is the best place to upload those files ? | 17:02:43 | |
| i mean you could put them on a pastebin. or https://tmp.lily.flowers/ | 17:03:21 | |
In reply to @keiichi:matrix.org* Prefetching that URL has nothing to do with npm trying to do something it shouldn't in the nix sandbox. Can you share the full log and the package-lock.json file you are using? | 17:03:41 | |
| https://tmp.lily.flowers/package.json and the package-lock.json https://tmp.lily.flowers/wuhszr | 17:06:22 | |
| can you share full build log? | 17:08:41 | |
| i don't see anything wrong with this lockfile | 17:08:46 | |
| I build it with :
and a nixpkgs of 8ac5c1191b06206f8508595f0c17332b851240f0 | 17:10:01 | |
| let me regenerate the log | 17:10:50 | |
| i mean i've got it building on my end now | 17:13:18 | |
| oh it's happening during prune...?? | 17:14:22 | |
| what the hell | 17:14:26 | |
| (why does npm prune logic always have to be so horribly busted) | 17:15:37 | |
yes. I haven't tried dontNpmPrune = true yet, trying | 17:25:18 | |
apparently npm prunes deps but then decides that the node_modules/@pulumi/query (that already has been reified when deps were built) is insufficient and needs to be re-reified. which would be fine except it also decides that the cache is for losers and ignores or otherwise gets too spooked by the existing entry for query-0.3.0.tgz | 17:27:43 | |
| whic | 17:28:00 | |
| * which | 17:28:01 | |
| makes no sense | 17:28:03 | |
| npm is very eager to silently get spooked and redownload though so i'm ultimately not surprised | 17:28:21 | |
| it would be nice to know whether it got spooked or didn't try the cache to begin with though (and even npm's debug logging does not log a lot of the situations where it gets spooked and bails for, unfortunately) | 17:28:54 | |
| dontNpmPrune "fixed" the build ty for help I hope this helps improving the understanding of npm xD | 17:30:03 | |
| i'm trying to root out the bug now | 17:33:18 | |
| in npm | 17:33:20 | |
| which upstream will invariably ignore a PR for but oh well | 17:33:28 | |
okay so npm is actually just removing the cache value from npmrc? | 17:39:14 | |