| 12 Nov 2023 |
 Lily Foster | In reply to @peter-lustig:matrix.org
updated yesterday i think like updated from nix{os,pkgs}-unstable or master or something? | 16:04:29 |
 peter-lustig | yes nixos-unstable | 16:05:02 |
| peter-lustig | and only right now, never had that before | 16:05:11 |
| Lily Foster | if you try again does it still happen? | 16:05:30 |
| Lily Foster | that's generally a transient network issue somewhere | 16:05:43 |
| peter-lustig | yep | 16:06:03 |
| Lily Foster | In reply to @lily:lily.flowers
and is it same dep? Same dep? | 16:06:16 |
| peter-lustig | i think so | 16:07:32 |
| peter-lustig | i try rebooting | 16:07:38 |
| Lily Foster | well i ask if it's same dep because if that one dep is from somewhere else (i.e. not npm registry) then that service may be having trouble from your location rn | 16:08:10 |
| Lily Foster | you can add RUST_LOG=debug env var if you want debugging output that may narrow down where it is going when it fails. also adding --cores 1 to your nix command so that way there's no parallelism | 16:09:03 |
| peter-lustig | ah okay | 16:09:03 |
| Lily Foster | In reply to @lily:lily.flowers
you can add RUST_LOG=debug env var if you want debugging output that may narrow down where it is going when it fails. also adding --cores 1 to your nix command so that way there's no parallelism (env vars for fetcher in buildNpmPackage can be added in postPatch) | 16:09:17 |
| Lily Foster | (like postPatch = "export RUST_LOG=debug") | 16:09:40 |
| peter-lustig | I wish there weren't these weird issues with these weird workarounds | 16:10:59 |
| Lily Foster | this is not a workarojnd | 16:11:18 |
| Lily Foster | * this is not a workaround | 16:11:22 |
| Lily Foster | i'm saying if you want debug output you can get it like that | 16:11:31 |
| Lily Foster | it will not fix anything | 16:11:35 |
| Lily Foster | but this is a network issue so i imagine it'll go away in a bit anyway | 16:12:05 |
| Lily Foster | so you could just take a break and come back later 🤷🏻♀️ | 16:12:29 |
| peter-lustig | In reply to @lily:lily.flowers
this is not a workaround I mean the non parallelism with just one core, that usually works for me | 16:13:51 |
| Lily Foster | how do you mean "usually works" exactly? | 16:14:11 |
| Lily Foster | we had a problem where network issues wouldn't properly be retried but that's been fixed on master for a few weeks and 23.05 for a few days | 16:14:40 |
| Lily Foster | if you think you're genuinely having issues with prefetch-npm-deps, can you please share your nixpkgs rev? | 16:16:00 |
| Lily Foster | (all of them if you have multiple nixpkgs in e.g. flake inputs, even if you don't think they should be used) | 16:16:25 |
| peter-lustig | In reply to @lily:lily.flowers
if you think you're genuinely having issues with prefetch-npm-deps, can you please share your nixpkgs rev? no I just experienced many little bugs over the years that were fixed and related to anything that has to do with nodejs and packaging. I guess it is just one of the weirdest things you can use on nix | 16:17:57 |
| Lily Foster | npm is very eager to do the wrong thing, so yeah unfortunately they were often there for a while | 16:49:38 |
| Lily Foster | 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 |
| Lily Foster | * 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 |
