Touch equivalent

Summary of the new feature / enhancement
Powershell is great, but there's a lot of very simple things that ideally shouldn't be quite as verbose as powershell requires. One of these is 'touch'
One thing for example is when I wanted to create the profile for my admin account, I would like to have been able to just do this:
@'
$PSReadLineOptions = @{
    EditMode = "Emacs"
    HistoryNoDuplicates = $true
    HistorySearchCursorMovesToEnd = $true
                ShowToolTips = $true
}
Set-PSReadLineOption @PSReadLineOptions
'@ > $profile

But that's a no go, because several paths along the way to where $profile pointed didn't exist. So instead you have to go through this:
mkdir -p $profile # Creates the entire path as a directory, including the very last item that should be just a file
rmdir $profile # Deletes the very last bit that should have been a file

@'
$PSReadLineOptions = @{
    EditMode = "Emacs"
    HistoryNoDuplicates = $true
    HistorySearchCursorMovesToEnd = $true
                ShowToolTips = $true
}
Set-PSReadLineOption @PSReadLineOptions
'@ > $profile

Would be nice if I could just do 'touch $profile' and be done with it, or if > would create the path and file if needed. Or even better: Both. Yes, I know you can just create an alias for it, but aliases don't really help all that much in a lot of cases, particularly in this situation. In cases like this where you're setting up an account you haven't used before, or even logging into a system you haven't used that particular account on before.
Proposed technical implementation details (optional)
No response

Duplicate of #8621, #13054 #13572, and #11677
Please add any additional comments / requests to the latter issue. 🙂

pwsh -c 'mkdir -p "$env:HOME/.config/powershell" '
$a= @'
$PSReadLineOptions = @{
EditMode = "Emacs"
HistoryNoDuplicates = $true
HistorySearchCursorMovesToEnd = $true
ShowToolTips = $true
}
Set-PSReadLineOption @PSReadLineOptions
'@
Set-Content -LiteralPath $PROFILE -Value $a
are you looking for a batch way to do this on every linux node?
use kasini3000 on windows master push linux version powershell to linux node,then run ps1 script batch.

kasini3000
win,linux devops automation batch script framework.(It is similar to Puppet，Ansible，pipeline)
Open source, free, cross-platform
English manual: https://gitee.com/chuanjiao10/kasini3000/blob/master/docs/kasini3000_manual.xlsx
kasini3000_agent_linux Shell script,one click install powershell on linux,modify sshd_config for PsRemote.


http://connectivity.cloudflareclient.com/

http://connectivity.cloudflareclient.com/
Originally posted by @YeshuaJesus1 in https://github.com/YeshuaJesus1/https-docs.github.com-en-enterprise-cloud-latest-organizations-managing-organization-settings-veri/issues/3

[```
🔐+🖥


MASSIVE COPYRIGHT VIOLATIONS!

I've discovered that nocode is in violation of every "New Project" ever created in a text editor with a blank workspace.
You'll be hearing from every software developer on the planet before long. Better lawyer up hard!

Umm... I believe it is those projects that violating nocode's license. Bring it on!

I think nocode has actually been released under every single open source license that exists. While I'm aware this may be contradictory I think we can safely use a version of nocode licensed under the MIT license without running into issues... but correct me if I'm wrong.

Nocode uses not enough of any of those project's code to be ever considered "infringing".
However every single one of those projects have used the entirety of nocode's source, without modification or permission, multiple times! I think there is a real case here.

Actually all the projects in the world are modified versions of nocode, they better should mention nocode in their licenses.


Failed to  build iOS

Bug report
Current behavior:
I trying to build a Test project for cordova-plugin-firebasex  and get this error:
InAppMessagingDisplayResources.bundle" not found. Run 'pod install'

Expected behavior:
To have a successfully build

Steps to reproduce:

Just follow the steps described in https://github.com/dpa99c/cordova-plugin-firebasex-test
Screenshots

**Environment information**

- Cordova CLI version
	- `cordova -v`
9.0.0<EMAIL_ADDRESS>- Cordova platform version
	- `cordova platform ls`
Installed platforms:
  ios 5.1.1
Available platforms:
  android ^8.0.0
  browser ^6.0.0
  electron ^1.0.0
  osx ^5.0.0
  windows ^7.0.0
- Plugins & versions installed in project (including this plugin)
    - `cordova plugin ls`
cordova-custom-config 5.1.0 "cordova-custom-config"
cordova-plugin-androidx 1.0.2 "cordova-plugin-androidx"
cordova-plugin-androidx-adapter 1.1.0 "cordova-plugin-androidx-adapter"
cordova-plugin-customfcmreceiver 1.0.0 "Custom FCM Receiver"
cordova-plugin-dialogs 1.3.2-dev "Notification"
cordova-plugin-enable-multidex 0.2.0 "Enable Multidex"
cordova-plugin-firebasex 9.0.1 "Google Firebase Plugin"
cordova-plugin-whitelist 1.3.4 "Whitelist"
- Dev machine OS and version, e.g.
    - OSX
        - `sw_vers`
ProductName:    Mac OS X
ProductVersion: 10.15.4
BuildVersion:   19E266
    - Windows 10
        - `winver`
Runtime issue

Device details

e.g. iPhone X, Samsung Galaxy S8, iPhone X Simulator, Pixel XL Emulator

OS details

e.g. iOS 12.2, Android 9.0

Android build issue:

Node JS version

node -v

Gradle version

ls platforms/android/.gradle

Target Android SDK version

android:targetSdkVersion in AndroidManifest.xml

Android SDK details

sdkmanager --list | sed -e '/Available Packages/q'

iOS build issue:

Node JS version

node -v
v12.16.1

Xcode version
Version 11.4 (11E146)

Related code:
insert any relevant code here such as plugin API calls / input parameters

Console output

console output

// Paste any relevant JS/native console output here

Other information:

Duplicate of #326.
See the documentation regarding this.
TL;DR: use<EMAIL_ADDRESS>when building from the CLI


feat(ui): clip skip in sdxl graphs (wip)

What type of PR is this? (check all applicable)

[ ] Refactor
[x] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation Update
[ ] Community Node Submission

Have you discussed this change with the InvokeAI team?

[ ] Yes
[ ] No, because:

Have you updated all relevant documentation?

[ ] Yes
[ ] No

Description
feat(ui): clip skip in sdxl graphs (wip)

Update metadata accumulator to have clip2_skip
Add ParamClip2Skip
Update activeLabel to display both clips
Update graph builders

TODO:

Update the extra addXToGraph helpers that interact with CLIP, I got a bit lost in this and setting it aside for now.

Related Tickets & Documents

Related Issue #
Closes #4583

QA Instructions, Screenshots, Recordings

Added/updated tests?

[ ] Yes
[ ] No : please replace this line with details on why tests
have not been included

[optional] Are there any post deployment tasks we need to perform?

Example model really needs this or else gens go gg sadly.
https://civitai.com/models/257749/pony-diffusion-v6-xl?modelVersionId=290640


Use of postgraphql on digital ocean

This is kind of a newby question. I am trying to make an app to try this postgraphql thing out before trying it with a larger project. I am trying to use it by having it create an api for a web app( built with React and Apollo to work with GraphQL) and an ios and android app (built with React and Apollo). The app is a simple app for people to manage their collection of mini trains.

So how do I set this up on digital ocean? I can get postgresql setup there, but how to install postgraphql, I don't know. I mostly do front end stuff and this setting up an api is confusing. Also is this even the right solution to use? Should I just use node.js and express to create the api?

The process is very similar (if not identical) to deploying a Node.js app to Digital Ocean 😊
This is a good tutorial outlining the process in general for Node.js: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-16-04
Here’s an issue where some users share their experiencing using PM2 with PostGraphQL in production: https://github.com/calebmer/postgraphql/issues/82
It may be also useful for you to check out the PostGraphQL as a library documentation: https://github.com/calebmer/postgraphql/blob/master/docs/library.md
I hope this helps! Please let us know if you have any more questions, and good luck 😊


RequireTypeResolution now is an interface instead of an annotation

Closes #7492
For full context please read the linked issue.

I'll address the comments soon but I'm moving it to draft as this is clearly not ready yet to be merge.

This PR is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.


Revamp Blog Page UI for Improved User Experience

fixes #58
This pull request implements a comprehensive redesign of the blog page UI, focusing on enhancing user engagement and readability. The new layout features an updated color scheme, streamlined navigation, and improved typography, ensuring a visually appealing and intuitive experience for users while promoting content discoverability

Hey @DeadmanAbir please review my PR.

This pull request implements a comprehensive redesign of the blog page UI, focusing on enhancing user engagement and readability. The new layout features an updated color scheme, streamlined navigation, and improved typography, ensuring a visually appealing and intuitive experience for users while promoting content discoverability
 Hey @DeadmanAbir please review my PR.

fixes #58 This pull request implements a comprehensive redesign of the blog page UI, focusing on enhancing user engagement and readability. The new layout features an updated color scheme, streamlined navigation, and improved typography, ensuring a visually appealing and intuitive experience for users while promoting content discoverability
 Hey @DeadmanAbir please review my PR.

The design implmentation looks good to me, but ned two changes-

The featured post text breaking in mobile view, need to fix the layout or featured post.

Implement the posts in such way that the first post  from posts array will be the featured post and then the rest posts will be shown.

hey @DeadmanAbir i have understood the changes will work on. them today and submit them

hey @DeadmanAbir i have understood the changes will work on. them today and submit them

Please complete the changes so that I can merge them before time!!

Hey @DeadmanAbir i have made is responsive please review the code.


[ENH] Add fig.mne container for colorbar

This fixes Issue 262 in mne_connectivity.
I added a fig.mne SimpleNamespace, which holds the Colorbar for a circular plot. This allows users to directly access the Colorbar after creating a figure using mne_connectivity.viz.plot_connectivity_circle, which calls mne.viz.circle._plot_connectivity_circle.
I will add something in the docstring of plot_connectivity_circle to describe this functionality and modify one of the examples to use it.

Sounds reasonable to me!

Thanks @ruuskas

Uggghhh forgot that we wanted this for 1.10 not 1.9. I'll revert quickly and then we'll bring it back in for 1.10

Back in main in fa28abf53276bb83de7e20b95f75c1944b568557
https://mne.tools/dev/changes/devel.html


how to open a float dockable?

There are several ways to float dockables.

Programmatically by call Docking.newWindow with the dockable.
User interaction by selecting the Window option on the settings menu of the dockable.
User interaction by physically dragging and dropping the window somewhere outside of existing frames.

Note that the dockable must return true for isFloatingAllowed for these to work.
Example of 3 can be seen here: https://github.com/andrewauclair/ModernDocking/blob/main/img/floating_panel.gif

thanks, could i have programmatically codes example?

thanks, could i have programmatically codes example?

I just added a sample for it, Floating Sample


[Errno 2] No such file or directory: 'D:/AI/voice-changer/audiosplitter_whisper/data\output\Gawr Gura Vocals.srt'

File "D:\AI\voice-changer\audiosplitter_whisper\split_audio.py", line 83, in extract_audio_with_srt
subs = pysrt.open(srt_file)
File "D:\AI\voice-changer\audiosplitter_whisper\split_audio.py", line 167, in process_audio_files
extract_audio_with_srt(audio_file_path, srt_file, speaker_segments_dir)
File "D:\AI\voice-changer\audiosplitter_whisper\split_audio.py", line 173, in
process_audio_files(input_folder)
FileNotFoundError: [Errno 2] No such file or directory: 'D:/AI/voice-changer/audiosplitter_whisper/data\output\Gawr Gura Vocals.srt'

This means that whisperX is not generating an srt file for your audio or either the audio file is not found so it's not doing transcription.  Can you try running vscode as admin to see if this helps?

Most likely due to the file having spaces, or the path needing to be adjusted based on the operating system.
original: D:/AI/voice-changer/audiosplitter_whisper/data\output\Gawr Gura Vocals.srt**
better: D:/AI/voice-changer/audiosplitter_whisper/data/output/Gawr-Gura-Vocals.srt
even better: D:\AI\voice-changer\audiosplitter_whisper\data\output\Gawr-Gura-Vocals.srt

same error here, ran vscode in administrator and tried have removed all spacing in the file path but still get the same error:
FileNotFoundError: [Errno 2] No such file or directory: 'C:/Users/djexs/Desktop/AI-TESTING/audio-output\output\vocals.srt'
the thing that caught my eye was the \ idk if this is intentional or the program decided ah let's switch over with the generated directories.

Simple solution for anyone else. Delete venv folder, redo installation. I forgot what I had changed the folder name from and didn't bother searching through files for something to edit.

Not able to reproduce on my end, if you guys have a way to reproduce this issue reliably, it would help greatly in debugging

I was having the same problem, and I just solved it.
The problem is that whisperX doesn't support torch v2.0.0 or lower.
I was okay with using lower versions of my favorite repos, and since I was using cuda v11.6, I had to do a clean install of cuda as well to upgrade torch.
Fortunately, it seems that you can use more than one version of cuda on Windows (modify the environment variables as needed), so I did a clean install of cuda to v11.8 and also installed torch v2.0.0. It's been working fine with no errors since then.

If anyone is having the same problem, here's how to fix it.

getting a FileNotFoundError but not finding the wav file, not the srt. This happens because whisperX doesn't support torch v2.0.0 or lower. I've been using torch v1.13.1 and CUDA 11.6 to use other repos. Luckily, I realized that Windows allows you to use multiple CUDAs by changing environment variables, so I fixed this by doing a clean install of torch v2.0.0 and CUDA 11.8.

like the original topic, not finding the srt file. I had this problem as soon as I solved problem #1. I tried debug in vscode, and I don't know much about ffmpeg, but it seems that ffmpeg is very sensitive to filenames, so I changed all the vocal filenames to numbers (0.wav, 1.wav, 2.wav ...) and this solved the problem. I think the problem is that he used a space instead of an underscore ( _ ) in the filename.

I ran into the same issue as OP with mixed forward and backslashes, and the way that I fixed as follows:

In split_audio.py, look for the line that defines the object "input_folder". Should be line 190 if using the cloned repository as of the time of this comment.
Append the definition with .replace("/","\") such that the updated statement looks like:
input_folder = filedialog.askdirectory(title="Select input folder").replace("/","\\")
I also encountered some separate permissions issues; make sure that you are running VS Code as an admin so that your terminal has elevated privileges, or run the python script from an elevated command prompt or power shell outside of VS Code.

I ran into the same issue as OP with mixed forward and backslashes, and the way that I fixed as follows:

In split_audio.py, look for the line that defines the object "input_folder". Should be line 190 if using the cloned repository as of the time of this comment.
Append the definition with .replace("/","") such that the updated statement looks like:
input_folder = filedialog.askdirectory(title="Select input folder").replace("/","\\")
I also encountered some separate permissions issues; make sure that you are running VS Code as an admin so that your terminal has elevated privileges, or run the python script from an elevated command prompt or power shell outside of VS Code.

Can confirm adding .replace("/", "\") at line 190 fixes the issue. In my experience this is a whisperx issue, I've been using whisperx on other occasions aside from Jarod's script facing the exact same issue.

I ran into the same issue as OP with mixed forward and backslashes, and the way that I fixed as follows:

In split_audio.py, look for the line that defines the object "input_folder". Should be line 190 if using the cloned repository as of the time of this comment.
Append the definition with .replace("/","") such that the updated statement looks like:
input_folder = filedialog.askdirectory(title="Select input folder").replace("/","\\")
I also encountered some separate permissions issues; make sure that you are running VS Code as an admin so that your terminal has elevated privileges, or run the python script from an elevated command prompt or power shell outside of VS Code.

Can confirm adding .replace("/", "") at line 190 fixes the issue. In my experience this is a whisperx issue, I've been using whisperx on other occasions aside from Jarod's script facing the exact same issue.

Sorry, been away from this for a bit.  From the error, it looks like it would be an edit for "/" with a single "" @dcheung07 rather than a "\" right?  There were some conflicting phrases there, but I'll go ahead and update it with the "".

I ran into the same issue as OP with mixed forward and backslashes, and the way that I fixed as follows:

In split_audio.py, look for the line that defines the object "input_folder". Should be line 190 if using the cloned repository as of the time of this comment.
Append the definition with .replace("/","") such that the updated statement looks like:
input_folder = filedialog.askdirectory(title="Select input folder").replace("/","\\")
I also encountered some separate permissions issues; make sure that you are running VS Code as an admin so that your terminal has elevated privileges, or run the python script from an elevated command prompt or power shell outside of VS Code.

Can confirm adding .replace("/", "") at line 190 fixes the issue. In my experience this is a whisperx issue, I've been using whisperx on other occasions aside from Jarod's script facing the exact same issue.

Sorry, been away from this for a bit. From the error, it looks like it would be an edit for "/" with a single "" @dcheung07 rather than a "" right? There were some conflicting phrases there, but I'll go ahead and update it with the "".
Actually, I realized the markdown of seems to be getting rid of the backslashes, so I'm gonna assume it is actually "\\" from the title of the issue

Tried reaching out on discord to give you some context before pushing an update :P But this is how the error shows up (at least for me);

I ran into the same issue as OP with mixed forward and backslashes, and the way that I fixed as follows:

In split_audio.py, look for the line that defines the object "input_folder". Should be line 190 if using the cloned repository as of the time of this comment.
Append the definition with .replace("/","") such that the updated statement looks like:
input_folder = filedialog.askdirectory(title="Select input folder").replace("/","\\")
I also encountered some separate permissions issues; make sure that you are running VS Code as an admin so that your terminal has elevated privileges, or run the python script from an elevated command prompt or power shell outside of VS Code.

Can confirm adding .replace("/", "") at line 190 fixes the issue. In my experience this is a whisperx issue, I've been using whisperx on other occasions aside from Jarod's script facing the exact same issue.

Sorry, been away from this for a bit. From the error, it looks like it would be an edit for "/" with a single "" @dcheung07 rather than a "" right? There were some conflicting phrases there, but I'll go ahead and update it with the "".
Actually, I realized the markdown of seems to be getting rid of the backslashes, so I'm gonna assume it is actually "\\" from the title of the issue

That's my bad, I didn't proof read, I did indeed use .replace("/", "\") to sort the issue, the error returning would along the lines file couldn't be found at c:\temp\sounds\test/output/testfile.srt so the replace change would correct the issue.

Actually, I realized the markdown of seems to be getting rid of the backslashes, so I'm gonna assume it is actually "\\" from the title of the issue

Yup this is correct, stupid markdown getting rid of double slashes, but using the specific code I quoted fixes the issue.
P.S. Thank you for your videos and for this script!

for me it was because one of the audio had no voice, therefore nothing to transcribe so it couldn't generate the srt. They need to make it so that muted audios are skipped and deleted

I had exactly the same issue (missing SRT).
I downgraded from Torch nightly to Torch Stable and it solved it.

Caution ! The correction with .replace("/","\\") makes MacOS usage of this project encountering an error.
On macOS and Linux, the folder paths usually use the forward slash (/) rather than backslashes (), which are typically used on Windows systems.
The path string management should change depending on the OS used to run the script.


Server rendering

Hi,
First of all awesome work on mobx guys, my code is getting some much cleaner ! :)
I'm having some issue with the server side rendering of mobx-react-devtools, it looks like the style properties aren't generated in the same order on the server/client.
Because of that I'm getting this issue:
React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) d="237">
<div style="border-style:solid;f

Do you think it could be an issue related to radium ?
There is some weird properties in the style as well:
panel:[object Object];button:[object Object];button-log:[object Object];button-log-active:[object Object];button-updates:[object Object];button-updates-active:[object Object];button-graph:[object Object];button-graph-active:[object Object]

Here is the generated markup:
Server:
<div style="position:fixed;height:26px;background-color:#fff;color:rgba(0, 0, 0, 0.8);border-radius:0 0 2px 2px;border-style:solid;border-width:0 1px 1px;border-color:rgba(0, 0, 0, 0.1);z-index:65000;font-family:Helvetica, sans-serif;display:flex;padding:0 5px;panel:[object Object];button:[object Object];button-log:[object Object];button-log-active:[object Object];button-updates:[object Object];button-updates-active:[object Object];button-graph:[object Object];button-graph-active:[object Object];top:0px;right:20px;" data-reactid="238">

Client:
<div style="border-style:solid;font-family:Helvetica, sans-serif;panel:[object Object];top:0px;padding:0 5px;border-radius:0 0 2px 2px;color:rgba(0, 0, 0, 0.8);position:fixed;button:[object Object];display:flex;right:20px;button-graph:[object Object];border-color:rgba(0, 0, 0, 0.1);button-graph-active:[object Object];button-updates-active:[object Object];border-width:0 1px 1px;background-color:#fff;z-index:65000;button-log-active:[object Object];button-updates:[object Object];height:26px;button-log:[object Object];" data-reactid="238">

Thanks

@maxs15, hi!

npm list | grep mobx-react-devtools in your project's folder gives version 4.0.5?
What browser are you using?
Can you try passing undocumented prop userAgent when using server rendering like this:

<DevTool userAgent={req.headers['user-agent']} />

(req here is express Request)

What version of nodejs are you using?

Yes I'm using the last version (4.0.5)
I'm using chrome 50.0.2661.94
Just tried using the userAgent but didn't change anything
I'm using node 5.6.0

Strange, could you please try https://github.com/mobxjs/mobx-react-devtools if the problem occurs there. (npm install; npm start)

I'm sorry, I mean https://github.com/mobxjs/mobx-react-todomvc

Good idea ! And apparently no issue there..
I'll try to investigate the differences I have on my project, will let you know if I find anything.
Thanks for the help Andy


zeroadPackages.zeroad-unwrapped: make it build on Hydra

This time for real, I hope.  I'm sorry for my incomplete advice;
the explicit dontRecurseIntoAttrs confused me about what's the default
behavior in here.
Things done

(nothing applies... no hashes change)

Oops, duplicate of https://github.com/NixOS/nixpkgs/pull/133379
I checked but a bit earlier...


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).

That appears to be a different error. This appears to be very specifically just an error somewhere in the renaming of folders.
Just tried using a requirements file off the shelf: https://github.com/google-research/kubric/blob/main/requirements.txt
I've added the full log including retries this time, showing how it's not always the same package, and retries will eventually succeed. (Also 300+MB of trash in the .tmp[______] folders in C:\Users\[____]\AppData\Local\uv\cache
Subsequent installs are fine after the first install (and fast!), as everything is already in the cache.
Contrasted with regular Python pip, which installs first try, with or without cache.
PS C:\dev\uv_test_uv> uv venv; .\.venv\Scripts\activate.ps1; uv pip install -r requirements.txt
Using Python 3.11.6 interpreter at C:\dev\uv_test_uv\.venv\Scripts\python.exe
Creating virtualenv at: .venv
Resolved 136 packages in 31.02s
error: Failed to download distributions
  Caused by: Failed to fetch wheel: regex==2023.12.25
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpXU7l5Y to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\IPIdPmnxfhPlAbb4aByib
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 216ms
   Built dill==<IP_ADDRESS>
error: Failed to download distributions
  Caused by: Failed to fetch wheel: fastavro==1.9.4
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpvibAxB to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\xESJmy5hSHMPWyOAki-mV
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 202ms
   Built crcmod==1.7
error: Failed to download distributions
  Caused by: Failed to unzip wheel: crcmod==1.7
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpuSxG40 to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\8seE9kMwlOJb0FO7kkUiO
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 168ms
   Built hdfs==2.7.3
   Built docopt==0.6.2
   Built promise==2.3
   Built pyjsparser==2.7.1
   Built cloudml-hypertune==0.1.0.dev6
error: Failed to download distributions
  Caused by: Failed to fetch wheel: rapidfuzz==3.6.1
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpnchaw9 to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\fslC-i4Ih5c8itkG3OCU1
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 199ms
   Built google-apitools==0.5.31                                                                                error: Failed to download distributions
  Caused by: Failed to fetch wheel: scikit-learn==1.4.1.post1
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpyPARfj to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\BTqIbBmeNiUJZ4iFLjvr5
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 187ms
error: Failed to download distributions
  Caused by: Failed to fetch wheel: scikit-learn==1.4.1.post1
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpQ9zLLc to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\N6_d31F0MmeWfay8zuoy1
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 198ms
error: Failed to download distributions
  Caused by: Failed to fetch wheel: pyarrow==11.0.0
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpoDjYqG to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\77wbDpLZdJXaCe7d8Bgl4
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 180ms
error: Failed to download distributions
  Caused by: Failed to fetch wheel: scipy==1.12.0
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\[____]\AppData\Local\uv\cache\.tmpJrQ1Eo to \\?\C:\Users\[____]\AppData\Local\uv\cache\archive-v0\oJCgnzumPreaL33Y2A_jb
  Caused by: Access is denied. (os error 5)
(.venv) PS C:\dev\uv_test_uv> uv pip install -r requirements.txt
Resolved 136 packages in 193ms
Downloaded 3 packages in 1m 30s
Installed 136 packages in 41.33s
 + absl-py==1.4.0
 + apache-beam==2.54.0
 + astunparse==1.6.3
 + attrs==23.2.0
 + bidict==0.23.0
 + cachetools==5.3.2
 + certifi==2024.2.2
 + charset-normalizer==3.3.2
 + click==8.1.7
 + cloudml-hypertune==0.1.0.dev6
 + cloudpickle==2.2.1
 + colorama==0.4.6
 + crcmod==1.7
 + dataclasses==0.6
 + deprecated==1.2.14
 + dill==<IP_ADDRESS>
 + dm-tree==0.1.8
 + dnspython==2.5.0
 + docopt==0.6.2
 + etils==1.7.0
 + fastavro==1.9.4
 + fasteners==0.19
 + flatbuffers==23.5.26
 + fsspec==2024.2.0
 + gast==0.5.4
 + google-api-core==2.17.1
 + google-apitools==0.5.31
 + google-auth==2.28.0
 + google-auth-httplib2==0.1.1
 + google-auth-oauthlib==1.2.0
 + google-cloud-aiplatform==1.42.0
 + google-cloud-bigquery==3.17.2
 + google-cloud-bigquery-storage==2.24.0
 + google-cloud-bigtable==2.23.0
 + google-cloud-core==2.4.1
 + google-cloud-datastore==2.19.0
 + google-cloud-dlp==3.15.1
 + google-cloud-language==2.13.1
 + google-cloud-pubsub==2.19.4
 + google-cloud-pubsublite==1.9.0
 + google-cloud-recommendations-ai==0.10.8
 + google-cloud-resource-manager==1.12.1
 + google-cloud-spanner==3.42.0
 + google-cloud-storage==2.14.0
 + google-cloud-videointelligence==2.13.1
 + google-cloud-vision==3.7.0
 + google-crc32c==1.5.0
 + google-pasta==0.2.0
 + google-resumable-media==2.7.0
 + googleapis-common-protos==1.62.0
 + grpc-google-iam-v1==0.13.0
 + grpc-interceptor==0.15.4
 + grpcio==1.60.1
 + grpcio-status==1.60.1
 + h5py==3.10.0
 + hdfs==2.7.3
 + httplib2==0.22.0
 + idna==3.6
 + imageio==2.34.0
 + importlib-resources==6.1.1
 + joblib==1.3.2
 + js2py==0.74
 + jsonpickle==3.0.2
 + jsonschema==4.21.1
 + jsonschema-specifications==2023.12.1
 + keras==2.15.0
 + levenshtein==0.25.0
 + libclang==16.0.6
 + markdown==3.5.2
 + markupsafe==2.1.5
 + ml-dtypes==0.2.0
 + munch==4.0.0
 + numpy==1.24.4
 + oauth2client==4.1.3
 + oauthlib==3.2.2
 + objsize==0.7.0
 + opt-einsum==3.3.0
 + orjson==3.9.14
 + overrides==7.7.0
 + packaging==23.2
 + pandas==2.2.0
 + pillow==10.2.0
 + promise==2.3
 + proto-plus==1.23.0
 + protobuf==4.25.3
 + psutil==5.9.8
 + pyarrow==11.0.0
 + pyarrow-hotfix==0.6
 + pyasn1==0.5.1
 + pyasn1-modules==0.3.0
 + pydot==1.4.2
 + pyjsparser==2.7.1
 + pymongo==4.6.1
 + pyparsing==3.1.1
 + pypng==0.20220715.0
 + pyquaternion==0.9.9
 + python-dateutil==2.8.2
 + python-levenshtein==0.25.0
 + pytz==2024.1
 + rapidfuzz==3.6.1
 + referencing==0.33.0
 + regex==2023.12.25
 + requests==2.31.0
 + requests-oauthlib==1.3.1
 + rpds-py==0.18.0
 + rsa==4.9
 + scikit-learn==1.4.1.post1
 + scipy==1.12.0
 + setuptools==69.1.0
 + shapely==2.0.3
 + singledispatchmethod==1.0
 + six==1.16.0
 + sqlparse==0.4.4
 + tensorboard==2.15.2
 + tensorboard-data-server==0.7.2
 + tensorflow==2.15.0
 + tensorflow-datasets==4.9.4
 + tensorflow-estimator==2.15.0
 + tensorflow-intel==2.15.0
 + tensorflow-io-gcs-filesystem==0.31.0
 + tensorflow-metadata==1.13.1
 + termcolor==2.4.0
 + threadpoolctl==3.3.0
 + toml==0.10.2
 + tqdm==4.66.2
 + traitlets==5.14.1
 + trimesh==4.1.3
 + typing-extensions==4.9.0
 + tzdata==2024.1
 + tzlocal==5.2
 + urllib3==2.2.0
(.venv) PS C:\dev\uv_test_uv>

I see, thanks for the log! Again, I have a different output sadly 😢. I think I am doing something wrong too.
In my case, it didn't found a compatible version of tensorflow. If you are interested, here I leave the details, but I think my case is unrelated to this issue.

(.venv) PS C:\Users\aucac\repos\exp-python\uv> uv pip install -r .\requirements.txt
  × No solution found when resolving dependencies:
  ╰─▶ Because only the following versions of tensorflow are available:
          tensorflow<=2.5.3
          tensorflow>=2.6.0,<=2.6.5
          tensorflow>=2.7.0,<=2.7.4
          tensorflow>=2.8.0,<=2.8.4
          tensorflow>=2.9.0,<=2.9.3
          tensorflow>=2.10.0,<=2.10.1
          tensorflow>=2.11.0,<=2.11.1
          tensorflow>=2.12.0,<=2.12.1
          tensorflow>=2.13.0,<=2.13.1
          tensorflow>=2.14.0,<=2.14.1
          tensorflow>=2.15.0
      and tensorflow==0.12.0 is unusable because no wheels are available with a matching Python ABI, we can conclude that any of:
          tensorflow<0.12.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==0.12.1 is unusable because no wheels are available with a matching Python ABI, we can conclude that any of:
          tensorflow<1.0.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.0.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.0.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.1.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.1.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.2.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.2.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.2.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.3.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.4.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.4.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.4.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.5.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.5.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.5.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.6.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.6.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.7.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.7.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.7.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.8.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.9.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.9.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.10.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.10.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.10.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.11.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.12.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.12.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.12.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.12.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.12.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.13.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.13.2
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.13.2 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.14.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.15.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.15.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.15.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.15.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.15.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==1.15.4 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<1.15.5
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==1.15.5 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.0.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.0.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.0.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.0.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.0.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.0.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.0.4 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.1.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.1.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.1.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.1.2
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.1.2 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.1.3 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.1.4
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.1.4 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.2.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.2.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.2.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.2.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.2.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.2.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.3.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.3.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.3.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.3.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.3.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.3.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.3.4 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.4.0
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.4.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.4.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.4.2
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.4.2 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.4.3 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.4.4
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.4.4 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.5.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.5.1
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.5.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.5.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.5.3
          tensorflow>2.5.3,<2.6.0
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.5.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.6.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.6.1
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.6.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.6.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.6.3
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.6.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.6.4 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.6.5
          tensorflow>2.6.5,<2.7.0
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.6.5 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.7.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.7.1
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.7.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.7.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.7.3
          tensorflow>2.7.4,<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.7.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.7.4 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.8.0
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.8.0 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.8.1 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.8.2
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.8.2 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.8.3 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.8.4
          tensorflow>2.8.4,<2.9.0
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.8.4 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.9.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.9.1
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.9.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.9.2 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.9.3
          tensorflow>2.9.3,<2.10.0
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.9.3 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.10.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.10.1
          tensorflow>2.10.1,<2.11.0
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.10.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.11.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.11.1
          tensorflow>2.11.1,<2.12.0
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.11.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.12.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.12.1
          tensorflow>2.12.1,<2.13.0
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.12.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.13.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.13.1
          tensorflow>2.13.1,<2.14.0
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.13.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.14.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that any of:
          tensorflow<2.14.1
          tensorflow>2.14.1,<2.15.0
       cannot be used.
      And because tensorflow==2.14.1 is unusable because no wheels are available with a matching Python ABI and tensorflow==2.15.0 is unusable because no wheels are available with a
      matching Python ABI, we can conclude that tensorflow<2.15.0.post1 cannot be used.
      And because tensorflow==2.15.0.post1 is unusable because no wheels are available with a matching Python ABI and you require tensorflow, we can conclude that the requirements are
      unsatisfiable.

      hint: Pre-releases are available for tensorflow in the requested range (e.g., 2.15.0rc1), but pre-releases weren't enabled (try: `--prerelease=allow`)

If somebody wants me to try something, just tell! 😄

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
(.venv) PS C:\Program Files\envs\n\n\n\naduv> uv pip install ipython

Resolved 16 packages in 1.68s

error: Failed to download distributions
  Caused by: Failed to fetch wheel: prompt-toolkit==3.0.43
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Program Files\envs\pipx\venvs\venvs\uv\uvcache\.tmpvKXHjN to \\?\C:\Program Files\envs\pipx\venvs\venvs\uv\uvcache\archive-v0\VF2P3BmAtyIqJo8V9e9Jb
  Caused by: Access is denied. (os error 5)

(.venv) PS C:\Program Files\envs\n\n\n\naduv> uv clean

Clearing cache at: C:\Program Files\envs\pipx\venvs\venvs\uv\uvcache
Removed 369 files (3.6MiB)

(.venv) PS C:\Program Files\envs\n\n\n\naduv> uv pip install ipython

Resolved 16 packages in 1.77s

error: Failed to download distributions
  Caused by: Failed to fetch wheel: pygments==2.17.2
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Program Files\envs\pipx\venvs\venvs\uv\uvcache\.tmpA8BLxj to \\?\C:\Program Files\envs\pipx\venvs\venvs\uv\uvcache\archive-v0\xoGgYMWlHY-hrr7FtBrhm
  Caused by: Access is denied. (os error 5)

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

For many packages I can just run uv pip install [package] again without using "uv clean" and it will work without the "os error 5" but with numpy 1.26.4 it triggers every time and I tried it 15 times in a row

I think this is an error when attempting to persist the unzipped wheel to the wheel cache?

I think this is an error when attempting to persist the unzipped wheel to the wheel cache?

The contents of the temp file in $UV_CACHE_DIR are unzipped when after the install fails but not sure if the process is asking the os to move the contents before the temp folder is created

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.)

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 think this issue may crop up in corporate or more secure environments that have some layer of security running over all processes.

Ah, this is consistent with the experience in the first post.

@Wofiel Our issue may be too niche to get traction (which I don't disagree with at this stage of uv) time to learn rust and attempt a PR

I think this issue may crop up in corporate or more secure environments that have some layer of security running over all processes.

Ah, this is consistent with the experience in the first post.

This is also consistent with my experience.
FWIW, the versions that it tripped up on were debugpy==1.8.1 and markdown-it-py==3.0.0.

Is anyone of you able to share (here or in private to<EMAIL_ADDRESS>what kind of security software or special windows settings you are running, so we can reproduce the failures you are experiencing?

I don't think there is anything special on my setup.

Runing gitbash
On windows 11
running python -m pip install -r requirements.txt works
running python -m uv pip install -r --system requirements.txt fails

Is it possible that the use of the UNC prefix is itself the problem?
If I created a branch that omitted them, would anyone here be willing to cargo build locally and test it?

I could try it in the week - but don't have the tooling set up at the moment.

Do you mean this: "\\?\C:\..."?

Yeah, that prefix on the file paths.

I don't know enough to help - but I definitely can't cd into "\?\C:" using powershell or bash
in powershel:
this works: cd C:\
this does not cd \\?\C:\

Just curious -- what if you take the output of pwd, and then ls that prefixed with \\?\?

Either way I'll put together a branch to remove these.

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.

That's interesting - though retrying multiple times sort of defeats the purpose of UV being so fast.
I wonder why pip success but UV fails.
(Note we do use an antivirus)

That's interesting - though retrying multiple times sort of defeats the purpose of UV being so fast.
I wonder why pip success but UV fails.
(Note we do use an antivirus)

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

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

Definitely want to fix this.

Oh interesting, I just noticed that this is always related (except for one comment here) to persisting to archive-v0. But it succeeds if you rerun?

I really need to be able to reproduce this in order to fix it. (The answer might be to retry with a timeout, but even that needs testing, and I need to determine the appropriate durations.) Can anyone share what antivirus they might be running that would trigger this?

Installed Avast but couldn't reproduce.

I used watchdog to see what files a being touched and it shows that numpy always fails when it gets to 37 MB libopenblas64 dll unsurprisingly

Maybe a mock test can be made that ensures uv pip install is tolerant to a file temporarily being locked for a few milliseconds

I got the same issue and i use Trellix and Zscaler.

Looking through documentation for Trellix, this may be triggered by https://docs.trellix.com/bundle/application-change-control-8.3.x-product-guide-windows/page/GUID-EE9619ED-4BAE-4A2D-9F5B-1D613B197F8C.html where the newly created (unzipped) DLL files are temporarily read/write protected while a determination is being made, ultimately an "allow" decision is made but uv tries to move those files while they are temporarily blocked, this may be highly architecturally dependent as there seems to be some communication between the end user client PC and the ePO policy server and additional latency there may impact the the frequency of this bug.

I will own this.

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.

Tested on uv==0.1.19 (with the exponential backoff). So far all good - no issues on my setup.

I'll optimistically close, but can re-open if anything comes up.

Upgrading to uv==0.1.20 fixed this for me.

Great, thank you!

for me most of the packages synced fine with version uv==0.1.20! But i still have issues with one package of i think bigger size (https://squidfunk.github.io/mkdocs-material/).
This leads to following error:
Resolved 1 package in 4ms
DEBUG No cache entry for: https://files.pythonhosted.org/packages/64/dc/9817689e3500b8e3967302201341dda7878f33d4ad089f9deb1126a091d7/mkdocs_material-9.5.13-py3-none-any.whl
DEBUG No credentials found for: https://files.pythonhosted.org/packages/64/dc/9817689e3500b8e3967302201341dda7878f33d4ad089f9deb1126a091d7/mkdocs_material-9.5.13-py3-none-any.whl
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
WARN Retrying rename from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0 due to transient error: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
error: Failed to download distributions
  Caused by: Failed to fetch wheel: mkdocs-material==9.5.13
  Caused by: Failed to read from the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\x\AppData\Local\uv\cache\.tmpXVEqoW to \\?\C:\Users\x\AppData\Local\uv\cache\archive-v0\ivw1_SgSoJofW7-c2dlZ0
  Caused by: Zugriff verweigert (os error 5)

Did this happen yet? https://github.com/astral-sh/uv/issues/1491#issuecomment-1974827245

Nope.

Ah okay, is there a tracking issue for that?

I can do it, I just haven’t seen evidence that it’s a problem.

To clarify: I understand that device paths can lead to confusing and incorrect behaviors. But we strip the device path prefix everywhere that matters (in my experience). So I'd like to understand why it would matter in the case above, for example.

One compelling reason, to me at least, is confusion for users. Until Rust happened I had quite literally never seen a UNC path in the wild; it was just some abstract concept I read about in the Windows APIs.
cc @mitsuhiko I'd be curious to get your opinion on this

I hit the issue again
Running:
python -m uv pip install --python 3.11 --reinstall pylance==0.10.3
Resulted in
error: failed to remove file `C:\Users\x\AppData\Local\Programs\Python\Python311\Lib\site-packages\numpy.libs/libopenblas64__v0.3.23-293-gc2f4bdbb-gcc_10_3_0-2bde3a66a51006b2b53eb373ff767a3f.dll`
  Caused by: Access is denied. (os error 5)

and re-running it resulted in
error: Cannot uninstall package; RECORD file not found at: C:\Users\x\AppData\Local\Programs\Python\Python311\Lib\site-packages\numpy-1.26.4.dist-info\RECORD

One compelling reason, to me at least, is confusion for users. Until Rust happened I had quite literally never seen a UNC path in the wild; it was just some abstract concept I read about in the Windows APIs.

Note that by removing the UNC prefix you're potentially introducing a regression if the path is longer than 256 characters. In practice I don't know whether this is likely here, but I'd be interested to know the motivating reason for adding them in the first place. Was it in response to a long path issue?
See this page for more info:
https://learn.microsoft.com/en-gb/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces

Was it in response to a long path issue?

I'm not a maintainer but I know the answer: that is the behavior of the standard library function to resolve a path. From my understanding it was basically a mistake but nobody can change it now. Instead, it's common to use the dunce crate or the normpath crate when you don't want to resolve symlinks.

We do use dunce and strip the prefix anywhere that it interfaces outside of standard library filesystem operations.

@mkleinbort - Did you install that package prior to the latest uv? It could be leftover from your virtual environment being in a bad state.

I'm open to changing to use the dunce-canonicalized version everywhere, but note that it doesn't, like, fully solve the problem. dunce will still return a UNC prefix if the path is longer than 260 characters.

The merged PR #2419 has thus far eliminated failures on the handful pip installs I've done since upgrading. Thanks @charliermarsh

@charliermarsh
Not sure - I hit this error just now trying to upgrade to uv==0.1.21 (I'm on 0.1.20)

(Running on gitbash on a windows machine)

Hi, I observed exactly this issue when testing my dev environment on windows with uv==0.1.39.
The problem randomly appears on two different machines. One is running windows directly - and the other is using WSL with a windows mount. So far, the issue disappared after trying it another time.

Ran into this issue with uv == 0.2.11, Python 3.12 and Windows 11 Pro. No specific enterprise extensions installed to Windows but we do have McAfee Antivirus installed.

Hi,
the latest version (uv 0.2.15 (bfc342da9 2024-06-24)) still has these issues. We see this on a certain percentage every on our Windows CI runners. They do have CrowdStrike messing with our workloads unfortunately - corporate policy 😢
The common denominator seems to be source distributions which uv tries to build wheels from. I've never seen this error for packages that are available as wheel.
Hypothesis: snakeoil scanners need more time to scan compressed archives (because of the decompression step) and uvs backoff algorithm just needs a little tweaking to accommodate for that.
A few source distribution only packages:  fire, odfpy, mapdata, pywinusb

A bunch of error messages for these packages
$ .\hatch.exe run all.py$INTERPRETER_VERSION`:cov
Creating environment: all.py3.11
Installing project
error: Failed to download and build `pywinusb==0.4.2`
  Caused by: Failed to write to the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmp3V6aqK\built-wheels-v3\.tmpsxHt5d\pywinusb-0.4.2 to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmp3V6aqK\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2\w4S16F7Zw7fjYe2QmhqM_\pywinusb-0.4.2.zip
  Caused by: Access is denied. (os error 5)

$ .\hatch.exe run all.py$INTERPRETER_VERSION`:cov
Creating environment: all.py3.9
Installing Python distribution: 3.9
Installing project
Checking dependencies
Syncing dependencies
error: Failed to download and build `odfpy==1.4.1`
  Caused by: Failed to write to the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmp30woUu\built-wheels-v3\.tmp7d4zhJ\odfpy-1.4.1 to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmp30woUu\built-wheels-v3\index\70e6dbc41e17fe7c\odfpy\1.4.1\J27cgvxiwwWDBSM2Tnauu\odfpy-1.4.1.tar.gz
  Caused by: Access is denied. (os error 5)

$ hatch run uv --version
Creating environment: default
Installing Python distribution: 3.11
Installing project in development mode
Checking dependencies
Syncing dependencies
error: Failed to download and build `mapdata==3.11.1`
  Caused by: Failed to write to the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmptBDtnM\built-wheels-v3\.tmpqFOiKl\mapdata-3.11.1 to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmptBDtnM\built-wheels-v3\index\70e6dbc41e17fe7c\mapdata\3.11.1\T7WG4FPsti03XVV0KCULn\mapdata-3.11.1.tar.gz
  Caused by: Access is denied. (os error 5)

$ hatch run uv --version
Creating environment: default
Installing Python distribution: 3.11
Installing project in development mode
Checking dependencies
Syncing dependencies
error: Failed to download and build `fire==0.6.0`
  Caused by: Failed to write to the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpVXpz23\built-wheels-v3\.tmpnCevMt\fire-0.6.0 to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpVXpz23\built-wheels-v3\index\70e6dbc41e17fe7c\fire\0.6.0\pD3XrlBXA8_x3S3TYSW2o\fire-0.6.0.tar.gz
  Caused by: Access is denied. (os error 5)

Never saw this kind of responsiveness in a project, respect! 🥇

@axel-kah With --verbose logs do you see logs indicating that we are retrying? e.g. "Retrying rename from...."
We have a maximum backoff of 10s which is pretty long. Do you think we should be waiting longer than that?

@zanieb I modified the hatch script to install source-only packages with the latest uv and it seems it does not use any retry at all. Maybe that's the root cause.

verbose output
$ hatch run provoke-issue
Creating environment: default
Installing project in development mode
Checking dependencies
Syncing dependencies
cmd [1] | D:\glb\GwsU8_zK\0\uv.exe --version
uv 0.2.15 (bfc342da9 2024-06-24)
cmd [2] | D:\glb\GwsU8_zK\0\uv.exe --verbose pip install fire pywinusb nptdms odfpy ipyvuetable
DEBUG uv 0.2.15
DEBUG Searching for Python interpreter in system toolchains
DEBUG Found cpython 3.11.9 at `d:\glb\GwsU8_zK\0\.hatch_data\env\virtual\foo\Scripts\python.exe` (active virtual environment)
DEBUG Using Python 3.11.9 environment at .hatch_data\env\virtual\foo\Scripts\python.exe
DEBUG Acquired lock for `.hatch_data\env\virtual\foo`
DEBUG At least one requirement is not satisfied: ipyvuetable
DEBUG Using request timeout of 30s
DEBUG Solving with installed Python version: 3.11.9
DEBUG Adding direct dependency: fire*
DEBUG Adding direct dependency: pywinusb*
DEBUG Adding direct dependency: nptdms*
DEBUG Adding direct dependency: odfpy*
DEBUG Adding direct dependency: ipyvuetable*
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/fire/
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/pywinusb/
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/nptdms/
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/odfpy/
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/ipyvuetable/
DEBUG Acquired lock for `\\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2`
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/packages/packages/38/b4/ecce4a3a0dac3b1bf5776943530cf4f36406fc9b3f4f3c31c8dcab2249eb/pywinusb-0.4.2.zip#sha256=e2f5e89f7b74239ca4843721a9bda0fc99014750630c189a176ec0e1b35e86df
DEBUG Acquired lock for `\\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\odfpy\1.4.1`
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/packages/packages/97/73/8ade73f6749177003f7ce3304f524774adda96e6aaab30ea79fd8fda7934/odfpy-1.4.1.tar.gz#sha256=db766a6e59c5103212f3cc92ec8dd50a0f3a02790233ed0b52148b70d3c438ec
DEBUG Searching for a compatible version of fire (*)
DEBUG Selecting: fire==0.6.0 (fire-0.6.0.tar.gz)
DEBUG Acquired lock for `\\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\fire\0.6.0`
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/packages/packages/1b/1b/84c63f592ecdfbb3d77d22a8d93c9b92791e4fa35677ad71a7d6449100f8/fire-0.6.0.tar.gz#sha256=54ec5b996ecdd3c0309c800324a0703d6da512241bc73b553db959d98de0aa66
DEBUG Acquired lock for `\\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\nptdms\1.9.0`
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/packages/packages/ff/05/8f560020155c1843d664248fb114e33eac0c1b3ad44fce6bfc2b5dd143c2/npTDMS-1.9.0.tar.gz#sha256=0e65c237e9d50b9b8e162b9c34171353a5ea05f4019c99c3e8ebc00722361cbc
DEBUG Downloading source distribution: odfpy==1.4.1
DEBUG Downloading source distribution: fire==0.6.0
DEBUG Downloading source distribution: nptdms==1.9.0
DEBUG Acquired lock for `\\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\ipyvuetable\0.4.0`
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/packages/packages/7f/dc/aeb142c5ab3563a8600c8d2409212d9ff7f869ff87adea1e1de252032f08/ipyvuetable-0.4.0.tar.gz#sha256=d88e4d87be451b3813e18a999bd3bb5800db38ba59c612e943029fd0804482e2
DEBUG Downloading source distribution: ipyvuetable==0.4.0
DEBUG Downloading source distribution: pywinusb==0.4.2
DEBUG Preparing metadata for: ipyvuetable==0.4.0
DEBUG No static `PKG-INFO` available for: ipyvuetable==0.4.0 (PkgInfo(UnsupportedMetadataVersion("2.1")))
DEBUG No static `pyproject.toml` available for: ipyvuetable==0.4.0 (MissingPyprojectToml)
INFO Ignoring empty directory
DEBUG Solving with installed Python version: 3.11.9
DEBUG Adding direct dependency: setuptools>=40.8.0
DEBUG No cache entry for: https://artifactory.acme.com/artifactory/api/pypi/pypi-acme-vir/simple/setuptools/
DEBUG Preparing metadata for: fire==0.6.0
DEBUG No static `PKG-INFO` available for: fire==0.6.0 (PkgInfo(UnsupportedMetadataVersion("2.1")))
DEBUG No static `pyproject.toml` available for: fire==0.6.0 (MissingPyprojectToml)
INFO Ignoring empty directory
DEBUG Preparing metadata for: nptdms==1.9.0
DEBUG No static `PKG-INFO` available for: nptdms==1.9.0 (PkgInfo(UnsupportedMetadataVersion("2.1")))
DEBUG No static `pyproject.toml` available for: nptdms==1.9.0 (PyprojectToml(FieldNotFound("project")))
INFO Ignoring empty directory
DEBUG Solving with installed Python version: 3.11.9
DEBUG Adding direct dependency: setuptools*
error: Failed to download and build `pywinusb==0.4.2`
  Caused by: Failed to write to the distribution cache
  Caused by: failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\.tmpc3E2Z7\pywinusb-0.4.2 to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2\or1SrhePMDCdKnzdyzMki\pywinusb-0.4.2.zip
  Caused by: Access is denied. (os error 5)

I also set RUST_LOG=trace and found only 1 or 2 instances of "Retrying rename from...." - but only during the initialization of the venv by hatch and not when uv installs the source-only packages.

Thanks for the details! I'll investigate.

And I believe I've found a suspicious line :) if you want to give it a try https://github.com/astral-sh/uv/pull/4605

Just want to share that we still see these failures quite regularly as of uv 0.2.21 (ebfe6d8fc 2024-07-03)
[2024-07-13T08:03:24.537Z] error: Failed to download and build `conan==2.4.1`
[2024-07-13T08:03:24.537Z]   Caused by: Failed to write to the distribution cache
[2024-07-13T08:03:24.537Z]   Caused by: failed to rename file from \\?\D:\Jenkins\workspace\shared\temp\.tmp3Js7SG\built-wheels-v3\.tmpIcR0og\conan-2.4.1 to \\?\D:\Jenkins\workspace\shared\temp\.tmp3Js7SG\built-wheels-v3\index\f85683082b98592e\conan\2.4.1\rxFYsdKad4Hg7UOBh8zRC\conan-2.4.1.tar.gz
[2024-07-13T08:03:24.537Z]   Caused by: Access is denied. (os error 5)

Just want to share that we still see these failures quite regularly as of uv 0.2.21 (ebfe6d8fc 2024-07-03)
[2024-07-13T08:03:24.537Z] error: Failed to download and build `conan==2.4.1`
[2024-07-13T08:03:24.537Z]   Caused by: Failed to write to the distribution cache
[2024-07-13T08:03:24.537Z]   Caused by: failed to rename file from \\?\D:\Jenkins\workspace\shared\temp\.tmp3Js7SG\built-wheels-v3\.tmpIcR0og\conan-2.4.1 to \\?\D:\Jenkins\workspace\shared\temp\.tmp3Js7SG\built-wheels-v3\index\f85683082b98592e\conan\2.4.1\rxFYsdKad4Hg7UOBh8zRC\conan-2.4.1.tar.gz
[2024-07-13T08:03:24.537Z]   Caused by: Access is denied. (os error 5)

I wonder in this case if the back off procedure is being used in the case where a temp build environment is being created to build a wheel for a package in isolation. This seems like in the case where an isolated build is needed the back off approach is not being used.

Yeah my guess is we're missing it somewhere but not sure where... I think @zanieb is planning to take a second look.

Ok more fixes coming in the next release.

I stress-tested v0.2.25 on our windows CI by focussing on source distributions only. They all passed and instead of failing because files in the cache can't be renamed, I finally see retrying warnings like these:
WARN Retrying rename from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpTFyAcI\built-wheels-v3\.tmpFqzuFu\pywinusb-0.4.2
to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpTFyAcI\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2\seIYCJmH_UpZwtxYdRGAe\pywinusb-0.4.2.zip due to transient error:
failed to rename file from \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpTFyAcI\built-wheels-v3\.tmpFqzuFu\pywinusb-0.4.2
to \\?\C:\Users\gitlabwinrunner\AppData\Local\Temp\.tmpTFyAcI\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2\seIYCJmH_UpZwtxYdRGAe\pywinusb-0.4.2.zip

🎉
Thanks a lot for your effort!

Wonderful! Thanks for following up <3

Clearly separate from the root cause here but since it's mentioned here:

I'm open to changing to use the dunce-canonicalized version everywhere, but note that it doesn't, like, fully solve the problem (if it is a problem). dunce will still return a UNC prefix if the path is longer than 260 characters.

@charliermarsh are you still open to this change? We're hitting this problem with pyvenv.cfg (the home path in particular) -- importing dynamic libraries from UNC-prefixed paths fails miserably for at least some Python versions. Happy to open another issue.

Do you mind opening a separate issue with more details? That sounds like a bug (as opposed to a spurious failure).On Jul 24, 2024, at 7:46 AM, Pavel Dikov @.***> wrote:
Clearly separate from the root cause here but since it's mentioned here:
I'm open to changing to use the dunce-canonicalized version everywhere, but note that it doesn't, like, fully solve the problem (if it is a problem). dunce will still return a UNC prefix if the path is longer than 260 characters.
@charliermarsh are you still open to this change? We're hitting this problem with pyvenv.cfg (the home path in particular) -- importing dynamic libraries from UNC-prefixed paths fails miserably for at least some Python versions. Happy to open another issue.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

There is no doubt that this is a problem caused by hard links, and pnpm often has various problems


OCPBUGS-7426: Add migrationDataStore field

Allow configuration of a datastore for migrated volumes
Fixes https://issues.redhat.com/browse/OCPBUGS-7426

/jira refresh

/jira refresh

Pre verify passed with pre merge build
https://github.com/openshift/vmware-vsphere-csi-driver-operator/pull/139#issuecomment-1441509411

/label cherry-pick-approved
/label qe-approved

/label backport-risk-assessed


Add typescript typings

There are still places that need more detail, but for now I think it's enough and better than nothing.

Any word on if this will ever get merged?

Idk. I also stopped using QEncode because it doesn't play well with some generic implementations of S3 Buckets, such as the MinIO implementation used by Storj. I moved to Coconut.


JBDS-3951 Installer needs to add the VirtualBox install directory to the PATH

Installer needs to add the VirtualBox install directory to the PATH

Current coverage is 82.65% (diff: 100%)

Merging #532 into master will increase coverage by 0.29%

@@             master       #532   diff @@
==========================================
  Files            25         25
  Lines          2370       2502   +132
  Methods         428        428
  Messages          0          0
  Branches        212        213     +1
==========================================
+ Hits           1952       2068   +116
- Misses          418        434    +16
  Partials          0          0

Powered by Codecov. Last update a78d65b...83b499d

test this

test this

test this

test this

test this

test this

Included into https://github.com/redhat-developer-tooling/developer-platform-install/pull/544.


Get Ip

Is there a way of getting the ip address of a GameProfile?

A GameProfile has no IP, it just describes the user.

Is there a way to get the IP of a User on the Server?


Chat-completion function-call

[feature]
2023-06-13, OpenAI release new model(gpt-3.5-turbo-0613) which support new param 'functions' and 'function-call' function-call
functions: A list of functions the model may generate JSON inputs for.
function_call: Controls how the model responds to function calls. "none" means the model does not call a function, and responds to the end-user. "auto" means the model can pick between an end-user or calling a function. Specifying a particular function via {"name":\ "my_function"} forces the model to call that function. "none" is the default when no functions are present. "auto" is the default if functions are present.

I created a fork adding the new capabilities @lumiseven , check it out: https://github.com/Eduardo-T/openai-java-20240614


PREDICTING FUEL EFFICIENCY WITH PYTHON

Description
Description
Shraddha Pattanshetti -649
Batch - 17
Type: documentation
Approach: Purpose, Introduction to fuel efficiency and code
Domain
Datascience with Python
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

I would like to work on this issue, in the documentation part @prathimacode-hub
Type: Documentation
Approach:
1)Introduction to fuel efficiency and ML algorithm to be used for the same.
2)ML Algorithm to predict the fuel efficieny based on various factors.
3)Coding part of the same
Number in the contributor list: 845

/assign
I would like to work on this.
Pankaj Sawnani - 935
Batch - 21
Issue No - #6380
Type: Doccumentation
Approach:
-> Introduction to Fuel efficiency.
-> Prediction using ML algorithm.
-> Advantages of algorithm and Conclusion.

Hello, I am Deepthi M with serial number:172, Batch-5. I would like to do audio on this issue.
My approach: a detailed explanation

Issue assigned to @deepthi1107 for audio contribution


Update changelog

Hi,
We have to update the changelog.
For that, we need to see changes between 1.2 and 1.2.5
After that, we'll be able to publish the new version to npm and improve the project
Thank you

I come from Your First PR on Twitter.
3 things:

Would be glad to keep my first PR to help out with this, but going to need guidance. Do you mean just updating CHANGELOG.md? How would I know what's changed between 1.2 and 1.2.5?

I noticed a typo in the js files in /lib/. Kickstarter is misspelled. Seems like a simple enough fix for a first PR as well?:

`/**

This file is part of the Kickstarter.

(c) iGitScor http://github.com/iGitScor/kicksterter

For the full copyright and license information, please view the LICENSE
file that was distributed with this source code.
*/`

Maybe add something in the README.md to explain what the kickstarter does? It seems unclear to me at first reading. But that's probably because I'm a newb :)

Hi @kmulligan,
sorry for the response delay
Welcome !
The task is to have a complete changelog, but unfortunately it's not up to date
You can make any improvement you mentioned above
Thank you


Configure maxFiles option for logging for auto log files removal

Old log files were not being removed right now. This will only keep limited log files (as per specified in maxFiles option).

Codecov Report

Merging #43 into master will decrease coverage by 0.07%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master      #43      +/-   ##
==========================================
- Coverage   83.63%   83.56%   -0.08%
==========================================
  Files          18       18
  Lines         880      882       +2
  Branches      126      126
==========================================
+ Hits          736      737       +1
- Misses        144      145       +1

Impacted Files
Coverage Δ

src/config/default.config.js
75% <100%> (ø)
:arrow_up:

src/utils/logger.js
67.74% <50%> (-0.6%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e3cc9d5...689fb9c. Read the comment docs.