pnpm.configHook: prevent hard linking on file systems without clone support#429554
Conversation
|
Seems reasonable. I completely missed the discussion in the issue, but I was theorizing that hard linking is causing modifications to the store that in turn cause cache misses. |
There was a problem hiding this comment.
Huge thanks for finding this!
It starts to make sense for me too, the biggest mystery was why it worked on my main machine (which uses btrfs, supporting copy on write), but not on my VM (which uses ext4, pnpm would fall back to hard linking)
This looks good, but running nixpkgs-review wouldn't hurt
I only tested this with the typespec package, build fine on my VM :)
|
Yeah, I guess I have been working too little with hard links even considering this to be the issue. But with all the data now gathered it all makes sense. Yes, I was running |
|
Do we need to backport this? |
Not necessarily, PNPM packages build on However if for any reason this bug manifests on stable, debugging it again wouldn't be fun, other than causing ~100-200 package rebuilds, backporting it should be safe. Since we backport all PNPM package updates, if we want to decrease the rebuilds we could bundle the backport of this PR with the next backport of a PNPM version bump. |
|
|
Successfully created backport PR for |
Fix #426636
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.