Use a workspace dependency for the top-level uniffi crate.

[mhammond]

This is only done for the top-level uniffi crate now, so really only impacts our examples and fixtures. It might be the case that we could extend this to the sub-crates but the versioning for them is less clear.

I can't see a good reason to not do this - is there one I'm missing?

[jplatte]

Personally, I specifically avoid workspace dependencies for example crates so that they can be copy-pasted to bootstrap a new project.

[mhammond]

Personally, I specifically avoid workspace dependencies for example crates so that they can be copy-pasted to bootstrap a new project.

That makes sense, but doesn't seem to apply here because we aren't referring to the crates copy of UniFFI - ie, a new project can't just copy the existing path = "..." entries either?

[mhammond]

(I was also slightly bothered by the fact that some examples did specify a version and some didn't, and it wasn't clear if this was intentional or actually changed the semantics)

[jplatte]

Right, in-workspace example crates generally use path dependencies so it's not exactly as easy as just copy-pasting. I would still argue that removing a path (if the version field is also set) is easier than looking up the version, but it's not like I'm strongly opposed to this change.

W.r.t. semantics of specifying a version for a path dependency or not, AFAIK specifying it means that (a) cargo checks that the version requirement matches the version field of the Cargo.toml at that path and (b) more importantly in most use cases, actually irrelevant here, allows the package to be published (pre-publish tests will be run against the latest crates.io release matching the version specification).

[bendk]

Looks good to me, let's get this in before the 0.26 release.