Rework workspace crates to get ready to publish them

[slp]

Publishing libkrun to crates.io requires to be able to publish also every crate in the workspace. This requires the following changes, addressed in this PR:

• Rename crates to avoid potential collisions in crates.io
• Start managing crate versions.
• Add missing fields to each crate's Cargo.toml

We're setting up versioning in two different formats:

• 0.1.0-$LIBKRUN_VERSION: For crates that are only intended to be consumed by libkrun, we're leaving the 0.1.0 and adding the main crate version. Only the latter will be updated.

• 0.1.0: For display and input, we're giving them an independent version, and will be updated on its own pace accoding to SemVer.

[mtjhrc]

So this technically implies the API of the internal crates is stable (which it really isn't). Instead can we use something like 0.1.0-1.17.3, where 0.1.0 is an unstable API version, and 1.17.3 is the libkrun version this is for.

Longer term for libkrun 2.x I would eventually want to make things like a VirtioDevice trait public, but crucially IMO this has to be versioned totally independently from libkrun "core". Suppose libkrun-2.0 could depend on krun-devices 2.0, but libkrun 2.1, could start depending on devices 3.0.0 etc. (Or also start the version numbers with 0 - I'm not sure). So only users who implement custom devices have to follow frequent API changes (but they opted into it), users who just use builtin devices can just depend on libkrun 2.x not doing any breaking changes.

[nohajc]

If you wanted to avoid publishing the internal crates altogether, would it be feasible to refactor them into modules? Afaik that's the only way around it.

[mtjhrc]

If you wanted to avoid publishing the internal crates altogether, would it be feasible to refactor them into modules? Afaik that's the only way around it.

Yes but problem is this effects the compilation speed I think and doesn't do incremental builds. Each crate is a compilation unit.

[slp]

TBH, I wasn't contemplating the possibility of anyone beyond libkrun using those crates. But if there are plans to do so, we can use your suggested 0.1.0-1.17.3.

[mtjhrc]

Btw the krun-display and krun-input were meant to be consumed externally from the beginning, I wouldn't say they are fully stable though but for the rest of 1.x they might as well be.
They provide Rust bindings to our C API for providing GPU displays and input devices, gui_vm example already depends on them.

[slp]

@mtjhrc in that case, I'd be inclined to use 0.1.0, without the -0.17.3, so we remember those must be versioned independently.

[jakecorrenti]

I'm more in favor of 0.1.0 and dropping the suffix. Do we really care what version of libkrun the internal crate is for if it's not stable?

[slp]

I'm more in favor of 0.1.0 and dropping the suffix. Do we really care what version of libkrun the internal crate is for if it's not stable?

If we don't add the suffix, we'd need to manually bump the version to an arbitrary number on every crate changed between libkrun releases, since we can't publish crate updates with the same version number.

[d-e-s-o]

Very cool, thanks for working on this. One question: have you thought through how things will work with the init.c file required by the devices crate? This may require some moving around of code and making sure it's included in published packages or may even be blocked on #632, I fear. I may be missing something, though.

[ggoodman]

Might that be helped with #593?

[d-e-s-o]

Might that be helped with #593?

Good point. I'd think that may help as well.

[slp]

@d-e-s-o @ggoodman For 1.x, I was expecting consumers of the library from crates.io to export KRUN_INIT_BINARY_PATH pointing to their own init. For 2.0 we'll have #593 plus a new init written in Rust. Do you see a problem with the 1.x approach?

[ggoodman]

Sounds plausible. The reason I proposed the PR is because that's the DX I prefer so I think I'm totally biased 😅.

[mtjhrc]

I mean the env var isn't great, but not sure if now is the time to change it.

Sounds plausible. The reason I proposed the PR is because that's the DX I prefer so I think I'm totally biased 😅.

Yeah but what we really want is no built-in init by default, no? But that also means introducing a built-time option to disable the baked in init. (or make it a default enabled feature I suppose?)
And then have a separate rust crate krun-init (like you have) which gives you the bytes you can pass into krun_set_init (or similar flow... ) explicitly.

I mean this is the right direction, not sure how much of that we want to include in 1.18 though, In principle I am not against it, especially if we also want to publish the crates it might be nice to include this. On the other hand 1.18 was supposed to be released last week and we have a growing queue of changes waiting for 2.0.

[d-e-s-o]

Do you see a problem with the 1.x approach?

I was just worried about the UX when one attempts to consume the library as a crates.io dependency and it just won't work by default. That being said, personally I am fine with anything that moves us closer to enabling consumption from crates.io (which this change is helping with), so I am fine with tackling issues step by step.

[slp]

I think this one gets us into a better (but not ideal) state for potential crates.io users. Then, for 2.0, we'll have the #593 and a Rust init, which will make everything smoother.

[mtjhrc]

LGTM, thanks!