▲ 94 ▼ uv: Unified Python packaging (astral.sh) submitted 2 years ago by uthredii@programming.dev to c/python@programming.dev 37 comments fedilink hide all child comments TL;DR: uv is an extremely fast Python package manager, written in Rust.
[+] hades@lemm.ee 9 points 2 years ago* (last edited 1 year ago) (10 children) [deleted] permalink fedilink source hideshow 10 child comments replies: [–] chrash0@lemmy.world 14 points 2 years ago (3 children) definitely not the real reason for a project like this to exist. Python package management can be nightmarish at times depending on what you’re doing. between barebones requirements.txt, Poetry, and the different condas there’s a ton of fragmentation, and none of them do everything you’d want in an ideal way. above and beyond speed, i think uv is another attempt at it. but it could just be another classic xkcd moment where now there’s just another standard to deal with permalink fedilink source parent hideshow 3 child comments replies: [–] FizzyOrange@programming.dev 7 points 2 years ago (2 children) uv is a drop-in replacement for pip. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is... permalink fedilink source parent hideshow 2 child comments replies: [–] chrash0@lemmy.world 4 points 2 years ago (1 child) as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip permalink fedilink source parent hideshow 1 child comment replies: [–] FizzyOrange@programming.dev 4 points 2 years ago they wouldn’t have made a different tool altogether if it was really a 1:1 replacement Why not? It's 10x faster. I think it might have some other new features but you don't need to use those. i doubt one person on the team could be using uv while everyone else sticks to pip This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable. It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright). permalink fedilink source parent [–] FizzyOrange@programming.dev 9 points 2 years ago (3 children) Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces that to about 7 seconds. That's a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time. permalink fedilink source parent hideshow 3 child comments replies: [–] drwho@beehaw.org 1 point 2 years ago (2 children) Just out of curiosity, how often do you have to run pip install? permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 4 points 2 years ago (1 child) I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure. And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want. permalink fedilink source parent hideshow 1 child comment replies: [–] drwho@beehaw.org 3 points 2 years ago No, that makes perfect sense. Thank you for explaining. I like hearing about other people's environments, because it gives perspective. permalink fedilink source parent [–] Solemarc@lemmy.world 6 points 2 years ago The performance is just a "nice to have". Python package management, especially at scale is infuriating. At work we use python microservices in docker containers and it infuriates me trying to update the one our team is responsible for. I always like to rant that python 3rd party package management tools are a mistake. We should've gone for an "as simple as possible" setup instead of all this. So I'm sceptical of UV on principle since it's yet another 3rd party package manager but if it can do all of this and not be a nightmare I'll be ok with it. permalink fedilink source parent [–] Midnitte@beehaw.org 2 points 2 years ago I think the main focus is around building out the tool chain - I would think being fast is just a side benefit and the main benefit is being written as the same language as what they want to use for the rest of "cargo" permalink fedilink source parent
[–] chrash0@lemmy.world 14 points 2 years ago (3 children) definitely not the real reason for a project like this to exist. Python package management can be nightmarish at times depending on what you’re doing. between barebones requirements.txt, Poetry, and the different condas there’s a ton of fragmentation, and none of them do everything you’d want in an ideal way. above and beyond speed, i think uv is another attempt at it. but it could just be another classic xkcd moment where now there’s just another standard to deal with permalink fedilink source parent hideshow 3 child comments replies: [–] FizzyOrange@programming.dev 7 points 2 years ago (2 children) uv is a drop-in replacement for pip. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is... permalink fedilink source parent hideshow 2 child comments replies: [–] chrash0@lemmy.world 4 points 2 years ago (1 child) as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip permalink fedilink source parent hideshow 1 child comment replies: [–] FizzyOrange@programming.dev 4 points 2 years ago they wouldn’t have made a different tool altogether if it was really a 1:1 replacement Why not? It's 10x faster. I think it might have some other new features but you don't need to use those. i doubt one person on the team could be using uv while everyone else sticks to pip This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable. It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright). permalink fedilink source parent
[–] FizzyOrange@programming.dev 7 points 2 years ago (2 children) uv is a drop-in replacement for pip. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is... permalink fedilink source parent hideshow 2 child comments replies: [–] chrash0@lemmy.world 4 points 2 years ago (1 child) as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip permalink fedilink source parent hideshow 1 child comment replies: [–] FizzyOrange@programming.dev 4 points 2 years ago they wouldn’t have made a different tool altogether if it was really a 1:1 replacement Why not? It's 10x faster. I think it might have some other new features but you don't need to use those. i doubt one person on the team could be using uv while everyone else sticks to pip This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable. It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright). permalink fedilink source parent
[–] chrash0@lemmy.world 4 points 2 years ago (1 child) as you might have guessed i haven’t really tried it, but i have been reading about it. that said i have used “drop in replacement” tools like this (we use pnpm at work), and a drop in replacement is not without quirks. they wouldn’t have made a different tool altogether if it was really a 1:1 replacement. just because the commands are the same doesn’t mean it behaves the same. i.e. i doubt one person on the team could be using uv while everyone else sticks to pip permalink fedilink source parent hideshow 1 child comment replies: [–] FizzyOrange@programming.dev 4 points 2 years ago they wouldn’t have made a different tool altogether if it was really a 1:1 replacement Why not? It's 10x faster. I think it might have some other new features but you don't need to use those. i doubt one person on the team could be using uv while everyone else sticks to pip This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable. It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright). permalink fedilink source parent
[–] FizzyOrange@programming.dev 4 points 2 years ago they wouldn’t have made a different tool altogether if it was really a 1:1 replacement Why not? It's 10x faster. I think it might have some other new features but you don't need to use those. i doubt one person on the team could be using uv while everyone else sticks to pip This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable. It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright). permalink fedilink source parent
[–] FizzyOrange@programming.dev 9 points 2 years ago (3 children) Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces that to about 7 seconds. That's a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time. permalink fedilink source parent hideshow 3 child comments replies: [–] drwho@beehaw.org 1 point 2 years ago (2 children) Just out of curiosity, how often do you have to run pip install? permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 4 points 2 years ago (1 child) I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure. And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want. permalink fedilink source parent hideshow 1 child comment replies: [–] drwho@beehaw.org 3 points 2 years ago No, that makes perfect sense. Thank you for explaining. I like hearing about other people's environments, because it gives perspective. permalink fedilink source parent
[–] drwho@beehaw.org 1 point 2 years ago (2 children) Just out of curiosity, how often do you have to run pip install? permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 4 points 2 years ago (1 child) I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure. And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want. permalink fedilink source parent hideshow 1 child comment replies: [–] drwho@beehaw.org 3 points 2 years ago No, that makes perfect sense. Thank you for explaining. I like hearing about other people's environments, because it gives perspective. permalink fedilink source parent
[–] FizzyOrange@programming.dev 4 points 2 years ago (1 child) I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure. And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want. permalink fedilink source parent hideshow 1 child comment replies: [–] drwho@beehaw.org 3 points 2 years ago No, that makes perfect sense. Thank you for explaining. I like hearing about other people's environments, because it gives perspective. permalink fedilink source parent
[–] drwho@beehaw.org 3 points 2 years ago No, that makes perfect sense. Thank you for explaining. I like hearing about other people's environments, because it gives perspective. permalink fedilink source parent
[–] Solemarc@lemmy.world 6 points 2 years ago The performance is just a "nice to have". Python package management, especially at scale is infuriating. At work we use python microservices in docker containers and it infuriates me trying to update the one our team is responsible for. I always like to rant that python 3rd party package management tools are a mistake. We should've gone for an "as simple as possible" setup instead of all this. So I'm sceptical of UV on principle since it's yet another 3rd party package manager but if it can do all of this and not be a nightmare I'll be ok with it. permalink fedilink source parent
[–] Midnitte@beehaw.org 2 points 2 years ago I think the main focus is around building out the tool chain - I would think being fast is just a side benefit and the main benefit is being written as the same language as what they want to use for the rest of "cargo" permalink fedilink source parent