Allow publishing with path dependencies without a version (RFC2906)

[vladimir-lu]

Problem

RFC #2906 specifies that you "No longer need both version and path to publish to Crates.io" here. Now that the tracking issue #8415 is in stable I feel like it's a missing feature aka a bug.

The problem is the one described in the RFC - a multi-member workspace should be able to specify mod-a = { path = "path-to-mod-a" } without specifying the version when publishing to crates.io.

Steps

1. Create a multi-member workspace
2. Add a dependency from one crate to another using only path = 'path'
3. Get the error: error: all dependencies must have a version specified when publishing.

Possible Solution(s)

No response

Notes

My apologies if this was already covered somewhere else but a search and reading through the comments on the RFC didn't yield anything about why this is not implemented. Or perhaps I just haven't found the way to do this yet and the docs need an update to clarify.

Version

cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Fedora 36 (ThirtySix) [64-bit]

[epage]

In #8415, we deviated from the RFC, including

Not inserting a version into path dependencies when publishing, see #8415 (comment)

[vladimir-lu]

@epage Thank you for pointing me to the discussion. Do you know if something was decided about this in the future (perhaps a workspace flag like for other workspace-inheritance related usages right now)? Otherwise I guess this can be closed.

[epage]

If it were to move forward, it will need to be re-examined from scratch. It didn't get the attention it needed in the initial RFC and has breaking changes and bad workflows that would need to be addressed. While its a neat idea, I don't think it would end up being worth the effort in practice.

[vladimir-lu]

As a user, the ability to keep the version consistent across the entire repo (here represented by a cargo workspace) is very useful, even if it means republishing new versions for crates where nothing changed, because of the simplicity of dealing with a single version rather than multiple. I can also see the argument why semver might imply that you should probably publish the most minimal version increment possible (what was being argued in the RFC comments), though for monorepo-managed applications that are also published to a registry there doesn't seem much practical benefit vs. the library case.

Right now, the workaround is to use cargo-edit (and I guess killercup/cargo-edit#752 already tracks the change there) which is good enough in practice for me.