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

Add an uv-managed Python to CI #13177

Open
The-Compiler opened this issue Jan 30, 2025 · 4 comments
Open

Add an uv-managed Python to CI #13177

The-Compiler opened this issue Jan 30, 2025 · 4 comments
Labels
type: infrastructure improvement to development/releases/CI structure

Comments

@The-Compiler
Copy link
Member

As demonstrated by #12888 and #13170, there is subtly different behavior regarding to input with uv-managed Pythons from python-build-standalone, as those use libedit instead of readline.

The existing tests in test_debugging.py mostly fail before #13176, so we would have easily caught #12888 earlier if we had a build job that runs with such a Python.

@The-Compiler The-Compiler added the type: infrastructure improvement to development/releases/CI structure label Jan 30, 2025
@webknjaz
Copy link
Member

This would mean marking those runtime supported. Is this desired?

@The-Compiler
Copy link
Member Author

I don't see why it wouldn't be. They are already in common use and will only get more common, so we can't just pretend they don't exist.

@nicoddemus
Copy link
Member

Sounds good to me. 👍

@namurphy
Copy link
Contributor

Thank you for raising this issue! If uv does get incorporated into CI, it would become reasonably straightforward to test against the minimum allowed versions of dependencies (which are being specified in #13317). These tests would provide information on when it's necessary to bump the minimum allowed versions of dependencies.

These tests could make use of uv's lowest-direct resolution strategy to find an environment for the lowest allowed versions of direct dependencies. (The lowest resolution strategy is also an option, but doesn't work well unless indirect dependencies provide minimum bounds on dependencies too.)

My use case is that it's fairly common in the scientific pythoniverse to test against the minimum allowed versions of dependencies. For example, SPEC 0 recommends that:

Support for core package dependencies be dropped 2 years after their initial release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: infrastructure improvement to development/releases/CI structure
Projects
None yet
Development

No branches or pull requests

4 participants