Add a new CARGO_PKG_AUTHORS environment variable

[TheNeikos]

This will allow crates to use the CARGO_PKG_AUTHORS env variable to get a comma
seperated list of the authors declared in the manifest.

Closes #2441

[TheNeikos]

Something that has been touched upon in #2441 is how to format authors.

I've gone with a join as it keeps the code simple.

[alexcrichton]

Looks reasonable to me, thanks @TheNeikos!

Curious what others on @rust-lang/tools think as well!

[alexcrichton]

Ok, got a chance to talk about this with @wycats yesterday, and the conclusion is that this seems fine to add, but for lists we probably want to go with colon-separated? Seems less likely to have a colon in the name at least other than a comma.

[joshtriplett]

@alexcrichton Less likely, but still possible. What about using the standard email format: Some Name some.name@example.org, "Last, First" first.last@example.com That format handles any kind of punctuation, and seems closer to what people expect with a list of names and emails.

[alexcrichton]

Oh this isn't necessarily for the format itself, moreso for joining two different names together (you can have multiple authors).

[joshtriplett]

@alexcrichton That's what I mean. If someone puts this into Cargo.toml:

authors = ["Person One <person.one@example.org>", "Person Two <person.two@example.com>"]

then the environment variable could contain Person One <person.one@example.org>, Person Two <person.two@example.com>, and a macro to return that for programmatic use could either return that as a string or as an array of strings.

If someone decided, for whatever reason, to have an author entry like "\"Person Two, with a comma\" <person.two@example.com>" (which I've seen in real emails, both to write "Last, First" and to write nominal suffixes), then that's still unambiguously parseable.

[TheNeikos]

So, a colon it is then?

authors = ["Person A", "Person, B"]

Would then be: Person A:Person, B ?

Asking to clarify.

This should also work for the concerns @joshtriplett brought up I think?

[alexcrichton]

@joshtriplett yeah although @wycats was thinking we'd use a colon instead of a comma. We currently don't have a macro to parse this out and it's possible for someone to say something like:

authors = ["foo:bar", "baz"]

where if we use a colon separator this would look like CARGO_PKG_AUTHORS=foo:bar:baz and there's no way to parse that out to the original. We could invent our own quoting syntax with escaping of quotes and the escapes themselves, but without some utility to parse the output it seems like a non-starter unfortunately.

[joshtriplett]

@alexcrichton How easily can we scan the entire ecosystem of Cargo.toml files and find out whether anyone currently uses a comma or colon in the Authors field? If Cargo bans a character there, then you can use anything you want. Otherwise, you'd want some kind of quoting/escaping, and for that, following rfc5322/rfc2822/rfc822 convention for "mailbox-list" seems like the right approach, along with requiring that each quoted string in the authors list follow the convention for one "mailbox". I feel certain that Rust has at least one compliant parser for that format, and generating it is relatively easy.

[alexcrichton]

Looks like colons and commas show up unfortunately. Colons show up in some HTTP addresses in the authors field and commas separate either names or multiple email addresses.

[joshtriplett]

@alexcrichton Odd to see HTTP URLs in the authors field; are people putting things like https://github.com/exampleusername in there? It's unfortunate if the metadata doesn't have any common format.

Regarding comma-separated names and email addresses: isn't the field a list? Are people writing authors=["author 1 <a1@example>, author 2 <a2@example>"] rather than authors=["author 1 <a1@example>", "author 2 <a2@example>"] ? That's definitely incorrect. (There are slightly more legitimate uses of comma inside a single author string, though.)

[alexcrichton]

Yeah that's basically what I saw from a quick grep, some names look like "last, first " I think.

[joshtriplett]

@alexcrichton Yeah, some businesses do that even in email headers: "Last, First" first.last@example.com

What about just escaping the names in a consistent way (for instance, always wrap them in single-quotes, and escape single-quotes and backslashes with backslashes), and then putting them in the environment variable separated by anything we like? That's easy enough to reverse back into a list of strings.

[alexcrichton]

The problem with creating our own syntax for this is then you end up needing to create a parser as well. We've tended to avoid that in the past for things like RUSTFLAGS as well, and I suspect that if we do it here we'd probably want to use the same syntax everywhere.

[bors]

☔ The latest upstream changes (presumably #2531) made this pull request unmergeable. Please resolve the merge conflicts.

[TheNeikos]

@alexcrichton Is this what was decided? Or should I put in some whitespace as well?

[alexcrichton]

The "comma separated" part here may no longer be right

[TheNeikos]

Oops you're right! Changed it in the commit, but forget here. On it.

[alexcrichton]

Looks good to me! Just a minor nit

[alexcrichton]

@bors: r+ dd26ce3

[bors]

⌛ Testing commit dd26ce3 with merge 34a7a06...

[bors]

☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64