Release crates on crates.io

[V02460]

Make pushing releases to crates.io part of the release process. This secures the mas-* canonical names for the project. It also helps me and other packagers with preparations for distro packaging.

[sandhose]

I'm curious, can you elaborate on how it makes distro packaging easier?
The service will be significantly annoying to distribute through crates.io, because it needs a bunch of static assets (translations, templates, frontend assets, OPA policy) which need to be built with other tools and that are not embedded in the binary.

[V02460]

Speaking for Fedora, its Rust Packaging Guidelines require each packaged library crate to be published on crates.io. This is done to avoid namespace and dependency problems. Another point is the available automation and tooling for Rust packaging, namely rust2rpm in this case, which is designed to work with crates.io.

The annoyances you describe sound like they can be helped by automation of the distribution steps. I have no previous experience with publication of Rust crates, but with some guidance I might assist you?

[sandhose]

The guidelines you linked do say:

Crates that contain only an application but no library interface MAY be packaged even if they are not published on crates.io, because those packages are leaves and cannot be depended on by other Rust crates.

Which is our case. MAS is effectively an application, not a library. We are effectively in the same case as this unaswered stackoverflow question, where we have other assets to ship other than the binary, which is not something crates.io/the cargo build system is made for.

At some point, I was embedding all the assets within the binary, but that got very impractical, especially when the number of different assets kind grew

[matrixbot]

For your information, this issue has been copied over to the Element fork of matrix-authentication-service: element-hq/matrix-authentication-service#1842