cargo publish refuses path= dependencies, even though it probably oughtn't

[nabijaczleweli]

Problem

cargo publish says

error: all dependencies must have a version specified when publishing.
dependency `iron` does not specify a version
Note: The published dependency will use the version from crates.io,
the `path` specification will be removed from the dependency declaration.

Steps

1. have

   [dependencies.iron]
   path = "vendor/iron-0.6.1"
   features = ["hyper-native-tls"]

   in your Cargo.toml
2. run cargo publish

Possible Solution(s)

Well. Don't? This has previously been #1565 and https://users.rust-lang.org/t/is-it-possible-to-publish-crates-with-path-specified/91497 however the forum bikesheds something unrelated while on the issue Crichton says

Such a feature is basically entirely incompatible with all of Cargo right now

and, maybe in 2017 it was. but in 2024 this is either (a) a staggering indictment of cargo as a whole or (b) an abject lie. This is trivially provable by running cargo build, or indeed cargo install --git on the same source.

These work and correctly resolve the dependency. Conversely, when publishing, cargo pretends this will not happen if it, uh... downloads the tarball itself and then runs cargo build there?
These are not fundamentally different, but this, once more (cf. #14001), contributes to anything-that-isn't-cargo-build being simply worse than downloading-the-tarball-yourself-and-running-cargo-build, by what appears to be an explicit decision.

Notes

Sure, validate all the paths point into the distribution tarball you're making, this seems reasonable, maybe even useful!

Version

cargo 1.78.0 (54d8815d0 2024-03-26)
release: 1.78.0
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: x86_64-pc-windows-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:Schannel)
os: Windows 10.0.14393 (Windows 10 Home) [64-bit]

[epage]

rust-lang/rfcs#3452 is the most recent attempt to design support for "nested" packages. The Cargo team recently reviewed this and it seems unlikely to go forward at this time, see rust-lang/rfcs#3452 (comment)

and, maybe in 2017 it was. but in 2024 this is either (a) a staggering indictment of cargo as a whole or (b) an abject lie. This is trivially provable by running cargo build, or indeed cargo install --git on the same source.

These work and correctly resolve the dependency.

It works locally and with git because those are pulling in concrete versions that are known how to resolve. When using the registry, users don't want to download every version of a package and wait for all of those Cargo.toml files to be parsed just to resolve their dependency tree. We operate off of Summarys of packages that are tracked in an Index. Putting nested packages in Summarys in the Index is one of the big complex problems to be solved, enough so that it makes it questionable whether this feature is worth it.

[epage]

As we are tracking nested packages in #2203, I'm closing in favor of that. If there is a reason for us to keep this open separately, let us know!

[nabijaczleweli]

I think I'd put the user's preference closer to "installing the package" than "not being able to install the package, quickly", but sure.