Maintenance 03-25

[ThetaSinner]

This is mostly version bumps, making clippy pass on tests and generally tidying up. There is a significant change that I came here to make though.

At the moment this works:

use hdk::prelude::*;

#[derive(SerializedBytes)]
struct Thing {
    field: u32,
}

Because both SerializedBytes and holochain_serial! get imported.

I find this thoroughly annoying because if you just try to write code where SerializedBytes is available, then you just import wherever::SerializedBytes and get a compile error about holochain_serial! not being available.

Like this, you get a clearer error message telling you that holochain_serialized_bytes is missing. It's the approach that serde is currently using. The downside is that, like serde, we have to have it as a direct dependency wherever we use it rather than re-exporting it. So the following would be valid only if holochain_serialized_bytes is a crate dependency:

use hdk::prelude::SerializedBytes;

#[derive(SerializedBytes)]
struct Thing {
    field: u32,
}

[jost-s]

You must be joking. 2000 lines maintenance?

Anyhow, what you're saying is that if you use SerializedBytes outside of the hdk, you get the error about holochain_serial!?

[jost-s]

I see the bulk is Cargo.lock. Phew!

[jost-s]

Wave goodbye!

[jost-s]

Booyakah!

[ThetaSinner]

Anyhow, what you're saying is that if you use SerializedBytes outside of the hdk, you get the error about holochain_serial!?

You can still use it, but every time you import SerializedBytes, you have to remember to import the macro that it calls into the same scope too:

use hdk::prelude::{SerializedBytes, holochain_serial};

#[derive(SerializedBytes)]
struct Thing {
    field: u32,
}

Even though you don't use the macro directly and the error message doesn't make it clear what you did wrong.

[jost-s]

Got it, so making it explicit. That's great.