-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uv tool run is giving "SyntaxError: Non-UTF-8 code starting with '\xe8' in file..." #12122
Comments
I believe this is the error you see when you attempt to use Python 3.7 on Windows with uv-installed executables (#11847). Does |
Hmm, yes that fixes it. But why is uv using Python 3.7? I have Python 3.8, 3.9, 3.10, 3.11, 3.12 and 3.13 installed, all via the official python.org installers. I installed python 3.7 via Actually, OK, I uninstalled Python 3.7 via Should I assume that preferring an older but uv-installed Python is a bug, and this is sufficient as a bug report for it, or would you like me to raise a new issue specifically for that problem? |
As a further note, even just |
The most useful thing would be if you could share the output of |
Maybe this would help? You can set default versions. |
|
Maybe try this?
From: https://docs.astral.sh/uv/reference/cli/#uv-python-pin--request You can also just look at all UV environment variables to see what the values are. |
Here you go - it does look like it searched for "managed installations" first, and gave up once it found one, without looking at the registry for later versions.
|
I think you are confusing uv-installed Python (managed) and Python installed with the Official Python Installer (system). If you want to prefer versions installed with the Official Python Installer, read: https://docs.astral.sh/uv/configuration/environment/#uv_python_preference uv by default looks for any uv-managed Python installs. Then, if it doesn't find any, it looks for system-installs. If you want to look for system-installs first by default, change the environment variable. I think what you are asking for with your issue is that the order of preference in which uv looks for versions should be: uv-managed 3.13 This functionality doesn't exist in uv as far as I'm aware. |
I’m not confusing them. I am very well aware of the difference. However, I am saying that it is a very unintuitive behaviour to prefer an older version of Python over a newer one based purely on how it was installed. I think it’s problematic enough to be called a bug (and from his response I thought @charliermarsh agreed). But if it’s not, I’m happy to raise it as an enhancement request to get it changed. For an example of why the current behaviour is bad, consider a new user who has installed Python 3.13 from python.org. They have heard that uv is awesome, and use it to create virtual environments. One day, they find out about |
Yeah, I'm aware this default can be confusing. Unfortunately, I think it'd also be confusing if you did
I do think it is reasonable for uv to prefer Python versions it manages over arbitrary ones on the system. I definitely empathize with the confusing user experience of automatic installs being picked up though. For posterity, some related issues: |
(I think what you may want is a |
That would work, yes. I find the current approach borderline-unusably bad (for my personal workflows). So anything that lets me say "use the latest non-development Python version you can find, regardless of where it comes from" would be a huge improvement. Pinning to a specific Python version via something like |
That makes sense. Sorry you ran into this rough edge. The only problem with that mode is it means we can't stop discovery early, we need to query every possible Python interpreter on your system before deciding which one to use. I expect that to be a fairly minor performance hit though, since we cache those queries. |
Thinking some more about it, wouldn't that happen even now if you had previously done And the way that I can understand it would be a breaking change, so not something you can do "just like that" - but do you have any evidence that users actually prefer the current approach1? Footnotes
|
If you do
I agree, this is what I suggested we should change (and we happen to be doing some related work that will enable this functionality). It might need to be deferred to a breaking release, I'm not sure yet. I think we could consider it a bug fix, but we usually err on the side of marking these as breaking out of an abundance of caution. I'm certain it will break someone's code . |
Thinking some more about this, I'm surprised you don't register your managed builds in the registry, as defined in PEP 514. If you did this, you would be consistent with other builds, and you would also be able to discover all Python interpreters1 in a single pass, by scanning the registry. Obviously this is only applicable on Windows - I don't know how discovery of non-uv installations of Python is handled on Unix. There doesn't seem to be an issue requesting PEP 514 support. Is it worth me creating one? Footnotes
|
PEP 514 support is implemented, it's still in preview though ( |
Question
Whenever I try to run a tool via
uvx
(oruv tool run
) I get an error:This is happening for (as far as I can see) every tool, and with older versions of uv as well as the current version. I've tested with uv 0.6.5, 0.6.4 and 0.5.30. It doesn't happen with
pipx run
, and it happens with multiple tools (I've tried nox, pdm, and pip) and which suggests that it's something specifically affecting uv.I'm pretty sure I've used
uvx
before without this error, so while it's likely to be something on my machine that is wrong, I don't know how to diagnose (or fix) the issue. If you can suggest any ways I can work out what's happening, I'd appreciate it.I'm running Windows 11, with Powershell Core 7.5 as my shell, and Python 3.13 as my default Python interpreter.
Platform
No response
Version
No response
The text was updated successfully, but these errors were encountered: