cargo publish does not convert relative paths when normalizing Cargo.toml

[kornelski]

Problem

When packaging, Cargo replaces inherited foo.workspace = true fields with their actual values from the workspace.

Cargo seems to be substituting the readme field with literal value from the workspace. However, the meaning of paths in readme and license-file file is different when the crate is used outside of a workspace, so the path needs to be adjusted accordingly.

When publishing a crate with readme.workspace = true, the published value is readme = "README.md" (same as in workspace's Cargo.toml), but the path is taken from the workspace in a parent directory, so the resolved value should be changed to readme = "../README.md" (or wherever the workspace is).

Steps

Example:
https://docs.rs/crate/zsplit-cli/0.3.0/source/Cargo.toml.orig
readme.workspace=true meant the README.md relative to the workspace, so in the workspace root.

https://docs.rs/crate/zsplit-cli/0.3.0/source/Cargo.toml
the published Cargo.toml has readme = "README.md", but without workspace that now means relative to the crate, and the crate is in zsplit-cli/ directory,
https://docs.rs/crate/zsplit-cli/0.3.0/source/.cargo_vcs_info.json

so the readme path changed from root/README.md to root/zsplit-cli/README.md.

Possible Solution(s)

normalization that resolves workspace inheritance needs to change base of the paths from the root to the crate's directory.

Notes

No response

Version

No response

[epage]

To ensure I understand, the published package should have readme = "../README.md"?

If so, the problem with that is it would point outside of the .crate. We rewrite paths and copy things around to make sure they are inside the .crate. Granted, I've not verified if all of that is working correctly. Looking at the initial commit it looks like we have tests for this.

[kornelski]

Eh, there are two conflicting problems here, so I guess it's a no-win scenario.

Fixup of ../README.md ensures that the README file ends up properly in the .crate file. That's good.

OTOH, without knowing what was the original path relative to repository root, it's difficult if not impossible to correctly interpret relative URLs in the README's markdown.

The problem is when markdown contains [link](relative/path) I need to know where relative/path is on GitHub (or other repo host). In a simple case of readme = "README.md" in a no-workspace crate the embedded URL is relative to package.repository + vcs_info.path_in_repo + package.readme. But when the README was outside of the crate, its URLs are relative to its old outside-crate location, like package.repository + (assume workspace root is repo root) + workspace.package.readme.

I guess I can use Cargo.toml.orig to identify workspace crates and just assume ../ prefix.

[weihanglo]

It may or may not help. Just FYI we've got env CARGO_PKG_README since #11645.

[ggwpez]

It may or may not help. Just FYI we've got env CARGO_PKG_README since #11645.

I try ![doc = include_str!(env!("CARGO_PKG_README"))] together with readme.workspace = true but it does not find the file.
PS: Resolved by #11645 (comment)