Access denied for `uv pip sync` on Windows

[jrkerns]

Within a given venv, running uv pip sync <requirement file> fails with Access is denied. This is on Windows.

(venv311) C:\Users\kraken>uv pip sync requirements.txt
error: failed to remove file `\\?\C:\Users\kraken\venv311\Scripts\uv.exe`
  Caused by: Access is denied. (os error 5)

[MichaReiser]

Thank you for reporting. This is related to #1327

[jrkerns]

Ah, I looked for something similar but missed it. Thanks!

[T-256]

I think deleting executable is not allowed when it's running, but it can rename itself.
I think solution here is to rename self to temp dir.

[inoa-jboliveira]

Just completing, the issue also happens with uv pip install uv --upgrade meaning uv can't replace its own executable. See closed issue #3239 above.
It is blocking us from adopting it for devs using Windows

[zanieb]

I would strongly recommend against managing uv as a Python package and use our installer and uv self update instead.

[inoa-jboliveira]

@zanieb We have issues on windows with the path and installing uv globally is not always possible.
Also if there is a uv installed inside the env, it will take priority over the one outside since the command will be replaced on env activation.

You cannot run uv self update if uv was installed in the env as package. BTW, it makes way more sense to version control uv this way -- also version lock it

[EricThomson]

Not a solution, but a workaround (and note I use uv within a conda environment). I hit this error when I installed uv within a virtual environment, but when I installed it in my base conda environment, so I could then use it in every created virtual environment, I stopped getting the error.

When I tried updating uv (or pip/setuptools) within the environment, that didn't help.

I know this won't help all users, but maybe the handful who stumble in here searching for the Caused by: Access is denied. (os error 5) that use conda. 🤷

[charliermarsh]

Yeah, in general you can "solve" this by installing uv outside of whatever environment you're trying to manage. uv doesn't need to be in a given virtual environment in order to operate on it (it's just a Rust binary, it can run over any environment or Python interpreter on your system).

(Of course I'd prefer not to error here though.)

[inoa-jboliveira]

Yeah, in general you can "solve" this by installing uv outside of whatever environment you're trying to manage.

That is not easy without the right permissions unless I download the binary and run it locally. It makes managing UV version way more difficult IMO.

In the end I resort to pip install uv and then I can use uv pip install <stuff> and other commands.

This is one of the 4 open tickets here preventing me from fully adopting uv. It is very close, but I still rely on several workarounds and other compromises with pip.

Would it be possible to check if the file you're going to write exists and then save a temp one then perform a rename operation?

fs::rename(temp_executable_path, &current_executable_path)

This operation would be atomic without first removing the original file which the Windows forbids. If that does not work, the solution would be somewhere in the lines of running UV from a temp executable.

[T-256]

That is not easy without the right permissions unless I download the binary and run it locally

Does #5455 solve your need? you can set CARGO_HOME env variable to where you have permissions before executing uv-installer; so uv will install there.