During update, gets error filename name too long when using uv and could not write production lockfile for project when using pip

[saddestboy]

Steps to Reproduce

1. Sync with uv enabled

Reusing already existing virtualenv
Generating production lockfile: path_to_workspace\requirements.lock
Generating dev lockfile: path_to_workspace\requirements-dev.lock
Installing dependencies
Resolved 130 packages in 11.41s
error: Failed to prepare distributions
  Caused by: Failed to fetch wheel: capstone-windows==3.0.4
  Caused by: Failed to build: `capstone-windows==3.0.4`
  Caused by: Build backend failed to build wheel through `build_wheel()` with exit code: 1
--- stdout:

--- stderr:
error: could not create 'build\bdist.win-amd64\wheel\Users\abcd\AppData\Local\uv\cache\builds-v0\.tmpvIujg8\Lib\site-packages': File name too long.
---
error: Installation of dependencies failed in venv at path_to_workspace\.venv. uv exited with status: exit code: 2

2. Then sync with uv disabled

Generating production lockfile: D:\BaiduNetdiskDownload\0_0\ctf_py_env\requirements.lock
error: could not write production lockfile for project
Caused by:
    0: unable to run pip-compile
    1: 系统找不到指定的文件。 (os error 2)

Expected Result

File name too long error should be detected when generating lock file, but not when installing it.

Actual Result

The error is detected during real installation and I cannot switch into pip to update them afterwards. (Haven't check whether I can update successfully before).

Note that there is an issue (astral-sh/uv#2410) of uv talking about the too long cache filename filename.

Version Info

commit: 0.37.0 (09b67c469 2024-07-20)
symlink support: true
uv enabled: true #this varies during the reproduce process.

Stacktrace

Stacktrace for the first step:

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: BaseThreadInitThunk
  16: RtlUserThreadStart

Stacktrace for the second step:

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: BaseThreadInitThunk
  16: RtlUserThreadStart