primitive-types: update to scale-info 0.9

[ascjones]

Latest scale-info release https://github.com/paritytech/scale-info/releases/tag/v0.9.0.

Required for paritytech/substrate#8615.

It removes the parity-scale-codec direct dependency, so might help with #552.

[ordian]

could you please update the changelogs as well?

[ordian]

It's quite unfortunate that a breaking change in scale-info propagates to every single crate.
The problem is largely parity-util-mem though.

premature approval

[ascjones]

It's quite unfortunate that a breaking change in scale-info propagates to every single crate.
The problem is largely parity-util-mem though.

Indeed it is very annoying. Perhaps we could follow the pattern with impl-codec etc. and have a impl-scale-info sub crate, that would generate the TypeInfo impl instead of using the derive. They are simple types so should be straightforward.

[ascjones]

Perhaps we could follow the pattern with impl-codec etc. and have a impl-scale-info sub crate

Gah, even then a version bump would still cascade up the dependency tree.

Once we have scale-info 1.0 we can relax the requirement here to 1, so then will only need bumping/rereleasing when there is a major version bump

[ordian]

Gah, even then a version bump would still cascade up the dependency tree.

Yes, the problem is largely the design of parity-util-mem and Rust Orphan Rules, which result in this cascade. I don't have a solution for this yet. But bumping versions is also not that hard.

[ordian]

Thanks!

[ascjones]

Hey @ordian, just had an idea: in order to prevent another release like this, what about if we expand the requirements for scale-info to e.g.

scale-info-crate = { package = "scale-info", version = ">=0.9, <2"

This means that when scale-info goes to 1.0 (soon) we won't need another release here. All we do is use the derives here so as long as the derive(TypeInfo) is valid (which it definitely will be for 1.0, then we are good.

[ordian]

Hey @ordian, just had an idea: in order to prevent another release like this, what about if we expand the requirements for scale-info to e.g.

scale-info-crate = { package = "scale-info", version = ">=0.9, <2"

This means that when scale-info goes to 1.0 (soon) we won't need another release here. All we do is use the derives here so as long as the derive(TypeInfo) is valid (which it definitely will be for 1.0, then we are good.

Brilliant! If you're confident it won't change in 1.0 and the tests won't break, then go ahead!

[ascjones]

Great, I'll try it out now and see if works.

[ascjones]

and the tests

Hm actually those tests were failing because that builder code has changed, looks like the CI doesn't run them with the scale-info feature.

Actually I don't think those tests provide much value, essentially just checking the generated code from scale-info-derive, so adding some unnecessary coupling.

[ordian]

Hm actually those tests were failing because that builder code has changed, looks like the CI doesn't run them with the scale-info feature.

The CI is being fixed in #559, looks like we lost travis at some point.

Actually I don't think those tests provide much value, essentially just checking the generated code from scale-info-derive, so adding some unnecessary coupling.

The tests are not a blocker for a breaking change actually (because it won't break compilation upstream), but I think they provide a value in making sure the generated derive is correct, but feel free to remove them.