-
Notifications
You must be signed in to change notification settings - Fork 47
chore: use uv for package management; hatchling for builds #572
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
Conversation
30182b3
to
962d6a0
Compare
This results in a faster installation over vanilla pip.
@@ -1011,7 +1011,11 @@ def install_pip_requirements(repositories): | |||
return | |||
|
|||
# TODO: Stop using system Python (#381) | |||
cmd = [sys.executable, "-mpip", "install", "--break-system-packages"] | |||
if shutil.which("uv"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like it could be risky, but I see that taskgraph's own tests are already running OK and end up here, so that's some level of confidence. (I suspect that we may see issues elsewhere for unpredictable reasons, but at least those ought to be caught in PRs as we start adding uv
to various docker images and/or workers.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm not sure I'm understanding the risk. Is the concern that uv pip install
will differ in some way from pip install
? That's a valid concern, but a design goal of uv pip install
is to be a drop-in replacement for pip install
. So it's certainly possible there are implementation errors, but if it ever deviates from pip install
they treat that as a bug. So far my confidence in this tool is very high.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also worth noting that we might not detect this via a patch to the repo if the repo is using an image from DockerHub and not pinning. But that's a tradeoff they decided to make, so I'm not too worried about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a huge concern or anything, I'm just calling out that changing the way we install packages is an inherent risk and notable change, and that we should watch out for bustage when we start hitting this code path in other projects. Certainly not a blocker for doing this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying! I do agree there is a level of risk here, but the perf boost is quite substantial. So I think it'll be worthwhile
No description provided.