Remove fetcherVersion = 1 and 2 from fetchPnpmDeps

[qweered]

To not introduce new usages and migrate to more reproducible fetcherVersion = 3

• various: migrate fetchPnpmDeps from fetcherVersion = 1 to fetcherVersion = 3 (part 1) #494404
• various: migrate fetchPnpmDeps from fetcherVersion = 1 to fetcherVersion = 3 (part 2) #494400
• various: migrate fetchPnpmDeps from fetcherVersion = 1 to fetcherVersion = 3 (part 3) #494401
• various: migrate fetchPnpmDeps from fetcherVersion = 1 to fetcherVersion = 3 (part 4) #494402
• opencloud-idp-web: apply patch to fix broken kopano tarball, migrate … #494213
• quantframe: 1.5.9 -> 1.6.12 #484972
• ocis: apply patch to fix broken kopano tarball, migrate to fetcherVersion = 3 #513204
• warn for fetcherVersion = 1 and docs - fetchPnpmDeps: deprecate fetcherVersion = 1, schedule removal for 26.11 #513215
• various: migrate fetchPnpmDeps from fetcherVersion = 2 to fetcherVersion = 3 (part 1) #514072
• various: migrate fetchPnpmDeps from fetcherVersion = 2 to fetcherVersion = 3 (part 2) #514073
• various: migrate fetchPnpmDeps from fetcherVersion = 2 to fetcherVersion = 3 (part 3) #514074
• various: migrate fetchPnpmDeps from fetcherVersion = 2 to fetcherVersion = 3 (part 4) #514075
• gui-for-singbox: 1.21.0 -> 1.23.2, migrate to fetcherVersion = 3 #514083
• warn for fetcherVersion = 2 and docs fetchPnpmDeps: deprecate fetcherVersion = 2, schedule removal for 26.11 #518360
• remove fetcherVersion 1, 2 and docs

[qweered]

cc @gepbird

[gepbird]

I was thinking of a slower, passive migration where we only allow fetcherVersion >= 3 for the upcoming pnpm_11 and we remove the older versions when the majority of packages have migrated. This would take a few months or even years though as the packages/upstreams are not the fastest with migrating to the latest version. Instances with grep:

• pnpm_8: 19
• pnpm_9: 184 (first release is Apr 16, 2024)
• pnpm_10: 139 (first release is Jan 7, 2025)

I'm not against an active migration, but I think we should have a longer period of fetchPnpmDeps warning for older versions rather than throwing immediately. I think phasing out versions 1 and 2 can be in the same PR, the treewide is fine how you started it.

make fetcherVersion = 3 default and remove need to specify it?

Please don't do this. The reason fetcherVersion was introduced in the first place is to allow us to modify the FOD output without having to regenerate hashes for all instances. Sure, we can control hashes inside nixpkgs (although mass hash changes for updates is discouraged), but out of tree pnpm packages will break.
For the second fetcher version version (first time we wanted to modify it) it solved a bug where the output was not reproducible and this solution changed most existing hashes.
So phasing out is out of the question, and even though it's +1 line for each package, I'd like to keep the version explicit otherwise from that change we'd need to assume the default is 3, maybe in the future we introduce a 4th version and make that the default, people who updated nixpkgs with default version 3 to default 4 will experience breakage, even if it's likely uncommon.

cc @Scrumplex

[RossSmyth]

The nice part about Nixpkgs is we can just mass migrate whenever we want to. There's no reason to wait if someone wants to put in the effort. There's no reason to be passive.

I do think that rather than removing them immediately, letting them emit a warning for a release cycle is good for external consumers ("this will stop working in 26.11, please migrate" or something).

[qweered]

Opened #513215

[qweered]

Opened 5 more prs migrating all fetcherVersion 2 -> 3, see header #494184 (comment)

[qweered]

cc @gepbird @Scrumplex for review