Publish puzzlefs to crates.io

[ariel-miculas]

https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html

[ariel-miculas]

@hallyn this needs a crates.io account linked to a github account as specified here. So I need your help with this. It would be nice for end users if puzzlefs was published to crates.io because they could install it with cargo install puzzlefs.

[hallyn]

@ariel-miculas Why do you need my help? Since the token is supposed to be a secret, it would be better for you to create it, right?

[ariel-miculas]

I've assumed you would like to be in charge of the crates.io account, of course I could do it if that's ok with you.

[hallyn]

Oh. Well, I don't quite understand how team membership works there. I suppose we should do it under the 'project machine' github repo? In which case I can do it.

[ariel-miculas]

It's tied to a personal github account as far as I can tell. I need to improve the documentation before publishing, let me check what else is needed. There's also a github action that could be used.

[hallyn]

So this seems to be a first-come-first-serve package name reservation system?

If I do the first crate publish, then henceforth only my own token will be able to push to it? Or can others push new versions?

I must be missing something, because this seems like a problematic design.

[ariel-miculas]

I don't think you're missing anything, the policy is defined here. But I've recently seen an article which tries to address some of the issues.

[ariel-miculas]

We actually need to publish multiple crates to crates.io, since puzzlefs is a workspace and not a single crate. The workspace has the following members (from the top-level Cargo.toml):

members = [
    "builder",
    "exe",
    "format",
    "oci",
    "reader",
    "compression",
    "extractor",
    "fsverity_helpers",
    "common"
]

We need a mapping between the name in crates.io and the crates in the workspace, e.g.:

builder -> puzlefs_builder
exe -> puzzlefs
format -> puzzlefs_format
oci -> puzzlefs_oci
reader -> puzzlefs_reader
compression -> puzzlefs_compression
extractor -> puzzlefs_extractor
fsverity_helpers -> puzzlefs_fsverity_helpers
common -> puzzlefs_common

Maybe even consider squashing some of these crates, or reorganizing them into the puzzlefs binary (exe) and a puzzlefs-lib which would contain all the other crates (builder, format, oci etc.). Also see this discussion

[hallyn]

Ok but so I'm fine either way - I can do it or you can. Please confirm one more time if you want me to.

[ariel-miculas]

@tych0 what's your take on this? Is it better to have only two crates, one for the executable and one for the library, or keep the existing organization with 9 crates?

[tych0]

I don't know anything about rust design, so take my advice with a grain of salt.

Yep, seems fine to consolidate into two crates. I definitely did not understand that we'd have to upload nine separate things to cargo.io if we wanted to keep the current organization, that seems crazy. I do think the organization is reasonable in terms of separation of concerns, but those can probably just be packages instead of whole crates.

[ariel-miculas]

Yeah, I agree, I will reorganize the code into and executable and a libary.

[hallyn]

I've created a cargo login token. When you have the code organized, let me know and i'll try a cargo publish.

[ariel-miculas]

Available at https://crates.io/crates/puzzlefs and https://crates.io/crates/puzzlefs-lib