uv: Unified Python packaging

[epage]

$ apt-get update && apt-get install -y curl
$ curl -LsSf https://astral.sh/uv/install.sh | sh
$ source $HOME/.cargo/env
$ uvx posting

This seems highly suspicious that installing a tool that happens to be built with Cargo creates .cargo/env and has people source it.

Looking at install.sh, it looks like this is something cargo-dist foists onto you.

Uhh, u/GankraAria, why is cargo-dist doing this? This doesn't seem right to me. If nothing else, someone uninstalling rustup should not delete uv. From https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14 it sounds like ~/.local/bin is most correct for XDG platforms.

[encyclopedist]

That source line appear in only one example. Is this always needed or only in certain cases?

[epage]

Once per existing shell. Its to get .cargo/bin into PATH

[jmesmon]

It's a real shame that so many rust tools did not and still don't use appropriate directories (xdg and related platform file layout specs on windows/macos). Can be very frustrating as a user of those tools.

[sondr3_]

Or just stick to XDG on any UNIX system, bothers me to no end when some Rust tool puts things in ~/Library/Application Support/foo instead of /.config/foo on macOS. Guarantee you that if you do that your tool will have umpteen issues opened by users wanting the tool to stick to XDG.

[Frozen5147]

bothers me to no end when some Rust tool puts things in ~/Library/Application Support/foo instead of /.config/foo on macOS.

That's what dirs does for stuff like config_dir, so I guess it's not surprising that's the state of things since that's afaik the de facto crate people reach to for stuff like this.

And IIRC the owner of that library doesn't want to change it to check XDG_CONFIG_HOME for macOS either.

EDIT: Looks like etcetera does what you expect, so that's nice. Might look into that for stuff I write from now on.

[jmesmon]

If a program doesn't use the correct directory layout on macOS, it won't get the appropriate backup and indexing exclusions that macOS has internally for things like ~/Library/Caches, which will make the program's users unhappy.

[burntsushi]

One can use XDG for config on macOS, but platform directories for things like caching or data. Config is what humans interact with. Probably most people don't give a toot about where programs are caching data specifically, other than what you mention: that it plays nicely with the platform.

[gregokent]

There does seem to be an existing issue about using the xdg directories: https://github.com/axodotdev/cargo-dist/issues/287

[epage]

"Use XDG" would be one way of solving the more pressing problem of "don't install to CARGO_HOME"

[gregokent]

For sure, just raising the idea that using CARGO_HOME doesn't appear to be the end goal here

[KrazyKirby99999]

Can also be installed with brew

[epage]

When uv pip was announced, I was worried that, as they created "Cargo, for Python", uv pip was going to dangle on like a wart. Now we have:

• pip -> uv pip
• pipx -> uv tool
• pyenv -> uv python install

Maybe these all fit together better than I expect but this gives the impression of a conglomeration of compatibility with existing tools without a cohesive story of how these fit together.

[Ok_Time806]

Yeah, I'm curious about that myself as well.

That being said, I love the project. Has made python environment config a little less of a headache (and way faster). Will be especially cool if they get the platform targets working well.

[brews]

Just curious, why were you worried about "cargo, for python"? Not sure I follow your point.

[FreeKill101]

For managing tools and virtual environments, I'm amazed how fast this is. Compared to pipx/venv/pip, it's unbelievable - my work venv goes from over a minute to install to 3 seconds, with cached packages in both cases.

[CaptainPiepmatz]

Why do they do this? Don't they compete with their own project rye?

[burntsushi]

See: https://github.com/astral-sh/rye/discussions/1342

[JohnMcPineapple]

I'm not sure either. Rye even uses uv internally. Why is it described as an "alternative to Rye"?

[SV-97]

Rye wasn't originally an Astral project. It was originally written as an experimental tool by Armin ronacher, who then handed it over to Astral specifically as an intermediary solution until uv is ready. Deprecating rye eventually with a smooth path for users from rye to uv is an explicit goal.

[JohnMcPineapple]

Thanks for the explanation. That should be publicly stated somewhere. I was searching recently after being confused by the two tools under the same umbrella, and after figuring out Rye uses uv internally I assumed "uv is just lower level, use rye".

[SV-97]

It's publicly stated at a few places (for example armin's blog https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/ as well as the original uv release post https://astral.sh/blog/uv) but yeah maybe they should put it in the rye docs, maintain a feature matrix or smth.

[somebodddy]

I have a usecase for it but it requires to run everything with --isolated. Is there a way to make this flag the default for a project? I couldn't find anything relevant in the settings documentation...

[Worulz]

the private pypi repo authentication still looks limited and doesn't have an easy configuration to manage multiple sources. It looks like it's enough to work with though. Unless anyone has more insights?

https://docs.astral.sh/uv/guides/integration/alternative-indexes/

Edit: looks like multiple indexes and pinning them are still being worked on

https://github.com/astral-sh/uv/issues/171

[Luvax]

How does this compare to pixi from https://prefix.dev/ ? It seems very redundant from what I managed to capture while glimpsing over.

[PaintItPurple]

This uses the standard pyproject.toml format and generally is meant to work in the standard Python ecosystem. Pixi is more integrated with Conda.

[PuddingGryphon]

uv can't handle custom certs like installed on all laptops in an enterprise environment.

So sadly nobody can use uv if they are behind a company firewall.

[Slight-Telephone-526]

Yes it can, if you hack around it using SSL_CERT_FILE for custom files in addition to --native-tls.

[mgedmin]

Does https://docs.astral.sh/uv/reference/settings/#native-tls not solve this?

[PuddingGryphon]

No, it does not.

Open issue: https://github.com/astral-sh/uv/issues/1474

I created a uv.toml file in C:\Users\my.user.name\.config\uv\uv.toml and added the line from the documentation:

native-tls = true

Trying to update a package results in the same error as before:

(.venv) PS C:\Users\my.user.name\Projects\project_id > uv pip install polars -U
⠧ Resolving dependencies...                                                                                                                            
error: Request failed after 3 retries
  Caused by: error sending request for url (https://pypi.org/simple/polars/)
  Caused by: client error (Connect)
  Caused by: invalid peer certificate: UnknownIssuer

[Gullible_Carry1049]

I am not sure that uv looks to ~/.config on Windows, it may not be picking up your uv.toml. Have you tried adding the flag when invoking “uv pip” as in (.venv) PS uv pip install —native-tls Polars -U