Relative paths in Cargo.toml readme

[kornelski]

I've found an odd case:

https://github.com/graphql-rust/juniper/blob/56f71e934be814722d10b0660156cf56b3753470/juniper/Cargo.toml#L12

1. The readme path is relative pointing to a parent directory: ../README.md,
2. there is no README.md in the .crate file,
3. and yet, miraculously, crates.io shows a readme: https://crates.io/crates/juniper/0.9.2

It seems the readme was snatched when the crate was published, with whatever filesystem access was temporarily possible at time of publishing. Unfortunately, it means it's not possible to get the README later from the package.

Could Cargo require the README to be in the package?

[dwijnand]

What should be done for this case? It's just a bit of an odd one.

[kornelski]

A simple client-side fix to Cargo would be:

1. When publishing, validate the readme path and check that it doesn't escape crate's root (root.join(readme).strip_prefix(root).is_some() perhaps?)
2. Check that the path is included in the package. If the crate uses include key, perhaps add it there, or warn if it's excluded.

Or rendering of README's could be moved to server-side. The server would read them from the actual package, so that authors would notice when the package is incomplete.

[dwijnand]

Yeah, there's a few different ways cargo could be more consistent, the whole spectrum from hard erroring, to warning, to accommodating. I'm just not sure what we prefer. 🙂

[dwijnand]

Mildly related, on publishing and README checking: #4861

[dwijnand]

In #6607 @ehuss suggests this fix:

copy the README somewhere into the package and rewrite the path in Cargo.toml

[stanislav-tkach]

I have just run into this issue. I think that it would be great if cargo could deal with it copying files outside of the crate directory, but in the meantime it would be nice to have a warning (personally I would prefer an error).