Ananthu and Louis-Philippe, thank you. Both of your responses were very helpful. On Friday, September 19, 2025 4:32:35 AM Mountain Standard Time Ananthu C V wrote: > Hi Soren, > > On Thu, Sep 18, 2025 at 02:08:47PM -0700, Soren Stoutner wrote: > > There are a couple of Python packages I maintain which have introduced new > > dependencies written in Python but containing Rust code. In particular, > > this > > email is regarding uv_build, which is a Python build system that is being > > adopted by a number of upstream projects whose packages I maintain. > > > > Manuel Guerra has been looking into how difficult it is to package uv_build. > > I will talk more about this below. > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1115616 > > > > By default, it wants to download Rust code at build-time based on a > > Cargo.toml. I assume this is not unique nor the first time this can come up > > with a Python package. My question is, what is the canonical way for > > handing > > such dependencies? > > The rust cargo wrapper is currently the way we usually go with, you > can refer to [0]. pollo already shared an example, some other ones are > python-orjson, pendulum etc. This is all under the impression of your > package not using uv_build itself as build backend, or you will have to either > switch it over to another build backend or wait until uv_build is packaged. > > Coming back to the packaging of uv_build, there is already ongoing > effor for packaging uv. But it is not easy as the dependency is tree > is quite huge. I'd expect most of it to be packaged though, but > there's a huge pain with uv itself. uv has an insane amount of > internal crates, none of which are in crates.io, which means the > typical rust team workflow can't be applied to them at least. A simple > 'find crates/ -maxdepth 1 -name uv-* -type d | wc -l' in the uv repo > will give you 61 as result, which is 60 other internal crates than uv > itself. Now uv_build does not require all of that, but working on this > will require a lot of things to be figured out first; such as what all > binaries need to be shipped, how to handle the build, etc. So it is > quite complicated and probably will take some time to get sorted out. > > [0] https://rust-team.pages.debian.net/book/process-workspace.html -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.