uv: uv pip install inconsistent failure on Windows
- Windows 22H2
- Using PowerShell env (in either Windows Terminal or powershell.exe, non-elevated)
When using uv pip install -r requirements.txt, I will frequently get the following error:
error: Failed to download distributions
Caused by: Failed to fetch wheel: setproctitle==1.3.3
Caused by: Failed to read from the distribution cache
Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\Temp\1\.tmp56ZHLz\.tmpMXOwQn to \\?\C:\Users\[____]\AppData\Local\Temp\1\.tmp56ZHLz\archive-v0\7RXhEx7TcTNKRTlP3vSED
Caused by: Access is denied. (os error 5)
This appears to be independent of the package, though seemingly happens more often with some than others.
If run with --no-cache, it’s almost impossible to install, as at least one thing is likely to fail in the process and progress restarted.
If run without --no-cache, retrying a number of times will eventually succeed (however, it will leave .tmp[_______] folders listed in the error messages in C:\Users\[____]\AppData\Local\uv\cache).
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Reactions: 4
- Comments: 57 (23 by maintainers)
Definitely want to fix this.
The \\?\ prefix is just a way around the MAX_PATH (256 char) limitation in Windows API calls. I’d personally be surprised if it had an impact although I couldn’t say for sure.
Having dealt with similar issues in other projects where Windows antivirus software is holding file locks after any file system operations, the best solution is usually just to retry the operation on failure a handful of times with a slightly increasing sleep in between attempts unfortunately.
I think this issue may crop up in corporate or more secure environments that have some layer of security running over all processes. I think there is a slight lag between when uv unzips the files where that process is ran in a sandbox and there is a slight delay before the os will allow access to the resulting folder while its scanned, I think simply catching the “os error” and retrying with some timeout would prevent this error on systems that have some security layer that temporarily effects permissions and also why a package like numpy (big and many small files) would consistently trip and medium packages would occasionally go through and occasionally trip.
i.e. you may not be able to re-produce this error in dev without setting up a test box that use one of these paid corporate security software to trigger it. You generally only create windows binaries on tagged releases, if you can create a dev build binary I can test it on my system
This will take some trial and error. I’ll add some improvements in the next release, and then look to folks in this thread for testing.
Oh, yes, happy if this is handled by uv
I just don’t want to write a bash script on my end to retry the installation till it works
I think the effect on speed would be imperceptible to the end user. The uv speed up is more to do with dependency resolution and retrying is to deal with likely milliseconds of time that a security layer on Windows locks access to the extracted zip contents before uv can read and copy the data from the tmp folder to the archive
Ah, this is consistent with the experience in the first post.
The overall approach is: unzip into a temporary folder, then move that folder into the cache to persist it. (This avoids persisting incomplete downloads that may error partway through.)
Just to add some more context to this, I get the same error and it will fail on different packages on each attempt if running uv clean in between
I suspect something in the temp file naming is randomly causing issues and after I tried 5 times with “uv clean” in-between it finished but it is happening frequently enough that there is a real issue. I am using the latest uv release 0.15 at the time of posting this issue