feat: upgrade to uv crates

[tdejager]

This moves from the outdated, pep_* crates to new the (newly) published uv-pep-* crates. These have seen great improvements in the last year and we have been using these in pixi succesfully.

To do this upgrade the rust version needed to be updated as well as fixing the clippy warnings that were introduced in the new toolchain.

Compatibility

The tests and snapshot tests all succeed, so this should not break the lock-file. However, the types have changed so this is definitely a major bump of the crate version. (Not sure if I need to do that in this PR). There is one normalization difference where: platform_system == 'Windows' is normalized to: sys_platform == 'win32'. I think this just a uv preference? So this might cause a bit of churn.

Next steps

When integrating this into pixi we can remove ALL of the uv-conversion code. Which I think is a huge boon.

AI Disclosure

• Most of the upgrade was done by Claude Sonnet. It seemed relatively straightforward.

[baszalmstra]

Before merging lets make sure core contributors are in agreement.

@pavelzw @wolfv Any objections to merging this? I assume this will have some downstream implications.

[tdejager]

I think the biggest change would be in the environment markers, because uv and the older open-source crates have a non-compatible (internal) version of this. AI is good at making comparisons for us: https://github.com/tdejager/pep-env-markers-demo

So there are some sets addes like extras and dependency-groups. Which error out in the pep_508rs versions. PyPA has this to say about it:

I'm guessing its not supported yet, but a tool is allowed to support it. Meaning, merging this we could potentially create a lock file, made with a uv project as source for example, that is not readable by older pixi versions. But this will currently be impossible with PyPI registry projects. I don't know if this should count as a breaking change or not? Thoughts?

[pavelzw]

So far, my developer experience working with uv as a rust dependency was not great. There were sometimes incompatibilities:

• https://github.com/Quantco/pixi-pack/blob/0e59ebd080f862ba3ec8114f67181bbaa6c3c741/src/unpack.rs#L68-L83 rayon being used by rattler and uv
• https://github.com/Quantco/pixi-pack/blob/0e59ebd080f862ba3ec8114f67181bbaa6c3c741/src/build_context.rs#L29-L67 need to mark a lot of stuff as unimplemented because we don't fill the intended use case in pixi-pack
• this whole liblzma-sys vs lzma-sys situation https://discord.com/channels/1082332781146800168/1212673297347518464/1372881237710082170
• sometimes getting things depending on pixi (like pixi-diff) to build was annoying (mostly uv-related build errors) (can't give you an explicit example anymore though).

I only bumped uv when i really needed to (also dependabot can't properly handle bumping git dependencies). With rattler requiring uv, this will lead to me needing to bump uv in pixi-pack as well on every rattler update to avoid version incompatibilities.

I liked that the rattler ecosystem was "closed-off" from uv and i didn't need to worry about uv things; developing conda-only tools (like conda-mirror or conda-deny) was really nice in that regard. I have not perceived the uv part of the supply chain as very stable (which is okay since they didn't publish crates for exactly that reason).
Not sure how things will play out now that they actually publish crates.
I worry a bit about worsening developer experience on the rust side if we start to require uv as a dependency. Also, if there was a problem, I usually was able to fix it relatively quickly by either creating a PR/issue in rattler or by posting a message in the prefix.dev discord. Needing an additional channel for potential issues (especially for non-conventional use cases for uv that might not receive the same level of support(??? you are probably a better judge of that than me)) can complicate things.

I tried this branch here out in Quantco/pixi-pack#243 and stumbled into another windows-only build error related to uv :/ Quantco/pixi-pack#243 (comment) (astral-sh/uv#16836)

[tdejager]

@pavelzw I think a lot of the problems came from using the entire mono-repo as a dependency, instead of just the pep crates here. These crates are now published on crates.io so you do not require the entire dependency tree and these are pretty low-level dependencies. Also these are a direct continuation of the open-source crates.

• rayon will probably? not used in these crates.
• build_context are not part of these crates.
• lzma thing I'm unsure about.

[tdejager]

Also as @konstin works for astral I suppose that the other crates will not see continued development :)

[konstin]

The pep440_rs and pep508_rs didn't really see any activity, so I'm focussing on the internal versions.

[pavelzw]

yeah most likely it will be fine. pixi-pack will still have some issues from time to time when updating its dependencies but i guess this is expected.

as long as we are careful about not pulling too many uv internals into rattler and keep our dependency tree somewhat clean, i guess it should be fine