Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release crates on crates.io #1842

Open
matrixbot opened this issue Sep 9, 2024 · 3 comments
Open

Release crates on crates.io #1842

matrixbot opened this issue Sep 9, 2024 · 3 comments
Labels
T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.

Comments

@matrixbot
Copy link
Collaborator

This issue was originally created by @V02460 at matrix-org/matrix-authentication-service#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 matrixbot added the T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. label Sep 9, 2024
@matrixbot
Copy link
Collaborator Author

This comment was originally posted by @sandhose at matrix-org/matrix-authentication-service#1842 (comment).

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
Copy link
Collaborator Author

This comment was originally posted by @V02460 at matrix-org/matrix-authentication-service#1842 (comment).

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
Copy link
Collaborator Author

This comment was originally posted by @sandhose at matrix-org/matrix-authentication-service#1842 (comment).

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks.
Projects
None yet
Development

No branches or pull requests

1 participant