Skip to content
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

Consider changing the default behaviour of python-preference #11039

Open
wzyboy opened this issue Jan 28, 2025 · 2 comments
Open

Consider changing the default behaviour of python-preference #11039

wzyboy opened this issue Jan 28, 2025 · 2 comments
Labels
enhancement New feature or improvement to existing functionality

Comments

@wzyboy
Copy link

wzyboy commented Jan 28, 2025

Summary

Currently the default value of python-preference is managed, which may cause confusion if user is not aware of this.

My Linux distro ships Python 3.13. If I haven't downloaded Python distributions with uv python, then uvx invokes system python (note python version = 3.13.1):

$ uvx --from ansible-core ansible --version
[...]
  python version = 3.13.1 (main, Dec  4 2024, 18:05:56) [GCC 14.2.1 20240910] (/home/wzyboy/.cache/uv/archive-v0/PI5AnOv_fdp-Cj5MJw9UF/bin/python)
[...]

$ readlink -f /home/wzyboy/.cache/uv/archive-v0/PI5AnOv_fdp-Cj5MJw9UF/bin/python
/usr/bin/python3.13

But once I downloaded any version of managed Python distributions, uvx uses the managed version (e.g. 3.11 below):

$ uvx --from ansible-core ansible --version
[...]
  python version = 3.11.11 (main, Jan  5 2025, 05:33:30) [Clang 19.1.6 ] (/home/wzyboy/.cache/uv/archive-v0/-guMtmimmxwb3QgDqwOIc/bin/python)
[...]

$ readlink -f /home/wzyboy/.cache/uv/archive-v0/-guMtmimmxwb3QgDqwOIc/bin/python
/home/wzyboy/.local/share/uv/python/cpython-3.11.11-linux-x86_64-gnu/bin/python3.11

This default behaviour is confusing because:

  • different versions of Python may have incompatibility
  • uv-managed Python behaves differently than system Python, espeically on Linux, e.g. use of libedit instead of GNU readline, use of musl instead of glibc, etc. (a bug caused by the incompatibility of libedit and readline is what led my surprise finding of python-preference option 😄 )

The fact that uv is ultra-fast makes the automatic installation of python versions even harder to notice. 😃 User might go into a random project that uses uv and unknowningly installed a managed version of Python that is different from system python. (the default behaviour is to auto-download Python)

Proposed Change

Only use managed version if running within a project, or if there is a .python-version file. For ad-hoc commands like uvx, always use system Python.

This could a new option like managed-if-within-a-project or something similar (sorry I'm bad at naming)

Example

No response

@wzyboy wzyboy added the enhancement New feature or improvement to existing functionality label Jan 28, 2025
@T-256
Copy link
Contributor

T-256 commented Jan 30, 2025

But once I downloaded any version of managed Python distributions, uvx uses the managed version

Current workaround is using user/system level's uv.toml, see here.

@wzyboy
Copy link
Author

wzyboy commented Jan 30, 2025

Thank you! I'm aware of the option that configures the default behaviour.

I'm suggesting this behaviour change because I fell for pitfall as a new user of uv and I hope future new users won't fall for the same pitfall like me.

My story, if anyone is interested:

Step 1: I discovered uv and immediately loved it. I tried the uvx feature a bit, and I gained the impression that uvx invokes system Python by default. I migrated my projects to use uv.

Step 2: A few days later, I used uv python download for the first time.

Step 3: More days passed, I was developing a project that migrated to uv in step 3. I wanted to test a code behaviour in an old release. Instead of doing git checkout v0.1, I just run uvx --from foo-package==0.1 foo /path/to/file as a one-time command, under the impression I gained from step 1 that this would invoke system Python, which is the same as the project venv.

Step 4: I continued to work on the git master version of the code, but this time there were some strange OSError that I never saw before.

I spent hours trying to debug OSError. The reasons behind this:

  • The venv in step 3 was created before step 2, linking to system Python (GNU readline)
  • I was under the impression that the uvx command in step 3 used system Python as well, but it actually used uv-managed Python (libedit)
  • The hisotory file generated by GNU readline and libedit are incompatible. In step 4, the OSError is raised because GNU readline was trying to process the file generated by libedit in step 3.

If the behaviour of uvx is consistent, i.e. does not change before/after a uv-managed Python is downloaded, this kind of confusing behaviour for new users can be avoided.

My use case might be niche, but there are other documented quirks of uv-managed Python distributions. Other users may encounter similar pitfalls like mine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement to existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants