search

element-hq / matrix-authentication-service

https://element-hq.github.io/matrix-authentication-service/
GNU Affero General Public License v3.0
38 stars 9 forks source link

Release crates on crates.io #1842

Open matrixbot opened 2 months ago

matrixbot commented 2 months ago

This issue was originally created by @V02460 at https://github.com/matrix-org/matrix-authentication-service/issues/1842.

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.

matrixbot commented 2 months ago

This comment was originally posted by @sandhose at https://github.com/matrix-org/matrix-authentication-service/issues/1842#issuecomment-1757567115.

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.

matrixbot commented 2 months ago

This comment was originally posted by @V02460 at https://github.com/matrix-org/matrix-authentication-service/issues/1842#issuecomment-1757983449.

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?

matrixbot commented 2 months ago

This comment was originally posted by @sandhose at https://github.com/matrix-org/matrix-authentication-service/issues/1842#issuecomment-1757995094.

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