Update uv_build version range in pyproject.toml

[ds-cbo]

uv-build 0.10 was released 2 weeks ago, making this cachecontrol package uninstallable in environments that have already updated their build tooling, this fixes that until next minor release

Note that uv-build follows the semver of uv despite only being a small subsection - in the release notes of 0.10 I couldn't find anything related to uv-build. Perhaps it would also be fine to increase the range to <1 to allow more leeway next time it updates

Also note that since moving to uv-build build times of cachecontrol have gone up considerably compared to when it was using flit. That plus this seeming instability of the tool would make me question whether it's already fit for use in a package as important as cachecontrol, but that's for another issue.

[woodruffw]

Thanks @ds-cbo, updating this range makes sense to me. I'd also be fine with widening the constraint like you said.

uv-build 0.10 was released 2 weeks ago, making this cachecontrol package uninstallable in environments that have already updated their build tooling, this fixes that until next minor release

Making sure I understand: you're pre-configuring the build environment with a specific build backend, rather than letting the build backend bootstrap its own version ranges? Is this a constraint imposed by distro packaging mechanisms?

Also note that since moving to uv-build build times of cachecontrol have gone up considerably compared to when it was using flit.

Do you have some stats you could share for this? I'd be interested in seeing them (and I suspect @konstin would too).

[konstin]

Note that uv-build follows the semver of uv despite only being a small subsection - in the release notes of 0.10 I couldn't find anything related to uv-build.

This is explicitly documented in https://github.com/astral-sh/uv/releases/tag/0.10.0:

There are no breaking changes to uv_build. If you have an upper bound in your [build-system] table, you should update it, e.g., from <0.10.0 to <0.11.0.

[ds-cbo]

Making sure I understand: you're pre-configuring the build environment with a specific build backend, rather than letting the build backend bootstrap its own version ranges? Is this a constraint imposed by distro packaging mechanisms?

Correct, we use the packaging environment from our distro (FreeBSD) where packages ("ports") ideally only have a single (and preferably most recent) version. If we have build instructions for uv-build 0.10 we lose the option to build (with) older versions like 0.9. We could get away with downgrading in this specific case, but generally speaking we prefer to stay up-to-date for security reasons.

Do you have some stats you could share for this? I'd be interested in seeing them (and I suspect @konstin would too).

I don't have stats to the second, but preparing uv-build for our build environment takes roughly 15 minutes, since it pulls in around 650 rust crates as dependencies and rust is not exactly known for compiling fast. We have no other python packages in our dependency tree that require uv-build, so to us this feels as a big increase in build times for just cachecontrol. After it's built once it can of course be reused until the next update, but because it has so many dependencies "the next update" happens often enough to be annoying, because even if uv-build or cachecontrol themselves didn't change, dependency upgrades still trigger a rebuild of them.

Of course there's much to say about how that's designed, but I hope you can understand that that system won't change overnight, so my "perceived build time" of cachecontrol has gone up considerably compared to when it was using flit before. But let's not make that a blocker for this specific PR :)

This is explicitly documented in https://github.com/astral-sh/uv/releases/tag/0.10.0:

My bad, I only scanned the bold headers, I missed that sentence

[woodruffw]

Thanks for explaining! Loosening the range here seems fine to me.