Fails to install with uv

[jku]

https://github.com/astral-sh/uv currently fails to install protobuf-specs: theupdateframework/tuf-on-ci#205

• uv does not accept pre-releases without an explicit --prerelease=allow
• this project depends on betterproto 2.0.0b6

It's been about four years since 2.0.0b1 so waiting for betterproto to release might not be a good strategy. If we consider this important we could offer to do some work to the maintainer if that helps them make a release?

[woodruffw]

It's been about four years since 2.0.0b1 so waiting for betterproto to release might not be a good strategy. If we consider this important we could offer to do some work to the maintainer if that helps them make a release?

Yeah, this would be ideal -- I've sent a few patches upstream to betterproto (in particular, fixing the handling of the Struct WKT), but I don't know how close they are to a stable 2.0 release.

(In particular, I still need to complete the fix in danielgtaylor/python-betterproto#559, which I'm still slightly murky on.)

More generally though, prereleases are part of PEP 440 and uv should support them, at least when fully pinned (e.g. protobuf-specs==2.0.0b6). So I think it might also be good to prod uv into finishing their prerelease support 🙂

[spencerschrock]

This is also affecting users installing the model-signing library (from sigstore/model-transparency) either directly or indirectly with uv.

e.g. Kaggle/kagglehub#224 (comment)

As mentioned in the original comment, 2.0 of betterproto isn't known, and uv has stricter ideas of pre-release.
https://docs.astral.sh/uv/pip/compatibility/#pre-release-compatibility

In the future, uv may support pre-release identifiers in transitive dependencies. However, it's likely contingent on evolution in the Python packaging specifications. The existing PEPs do not cover "dependency resolution" and are instead focused on behavior for a single version specifier. As such, there are unresolved questions around the correct and intended behavior for pre-releases in the packaging ecosystem more broadly.

I don't follow PEPs too closely, so I don't know if anything has changed that would help uv "finish their prerelease support"?

[woodruffw]

I think on the PEP side, the handling of precisely-pinned prereleases is well-defined -- uv should be supporting betterproto==2.0.0b6 (or whatever), since the user isn't asking for any prerelease resolution logic.

astral-sh/uv#11483 seems to be tracking that as a more tractable variant of the prerelease resolution problem (which they're correct to note isn't well defined) 🙂

[woodruffw]

I would have expected uv run --with sigstore-protobuf-specs==0.4.1 --prerelease explicit python to work, but that produces the same prerelease failure:

$ uv run --with sigstore-protobuf-specs==0.4.1 --prerelease=explicit python
  × No solution found when resolving `--with` dependencies:
  ╰─▶ Because there is no version of betterproto==2.0.0b7 and
      sigstore-protobuf-specs==0.4.1 depends on betterproto==2.0.0b7, we can
      conclude that sigstore-protobuf-specs==0.4.1 cannot be used.
      And because you require sigstore-protobuf-specs==0.4.1, we can conclude
      that your requirements are unsatisfiable.

      hint: `betterproto` was requested with a pre-release marker (e.g.,
      betterproto==2.0.0b7), but pre-releases weren't enabled (try:
      `--prerelease=allow`)

However, --prerelease allow does work:

$ uv run --with sigstore-protobuf-specs==0.4.1 --prerelease=allow python
Installed 14 packages in 21ms
Python 3.13.2 (main, Feb 12 2025, 14:59:08) [Clang 19.1.6 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sigstore_protobuf_specs
>>> 

Given that, uv users should probably do --prerelease=allow for now, or configure the same via their uv.toml/pyproject.toml.

[woodruffw]

xref sigstore/sigstore-python#1049 as well

[stefanberger]

The author of betterproto suggested to migrate to betterproto2: danielgtaylor/python-betterproto#678 (comment)

[woodruffw]

This is actually a non-issue for us now, since we've removed our dependency on protobufs/betterproto entirely in sigstore-python.

(This library itself is still not installable with uv, but IMO a better course of action here would be to deprecate the Python bindings here and point users towards sigstore-models as the alternative.)

[woodruffw]

Oops, didn't mean to close. This is still an issue in sigstore-protobuf-specs, just not in sigstore-python.