Symlink-or-copy `LICENSE` / `LICENSE-*` in workspace root when creating new member

[epage]

Problem

I just ran cargo new in a workspace and I had to manually copy over the license files.

Proposed Solution

LICENSE / LICENSE-* file names are a fairly strong convention that automatically linking them into a new package automatically seems to fit in along with our other workspace inheritance logic.

iirc we automatically move workspace.package.license-file into the package on publish, so we could skip this if that is set.

Notes

No response

[BatmanAoD]

Related question: what is the expected behavior for Cargo's source-downloading when it sees these files? The symlink-handling PR explicitly specifies that it handles directories but not files.

On Mac OS, with Cargo 1.82, it appears that a LICENSE symlink is downloaded as a normal file, with the content being the target filepath of the symlink, e.g. the literal text ../LICENSE. I'm not sure if this is the same across all platforms.

(It seems that setting core.symlinks=true in my git config does not affect this behavior, even with CARGO_NET_GIT_FETCH_WITH_CLI.)

[weihanglo]

@BatmanAoD Note that the PR you linked is quite old, and the relevant code has changed over time. And your situation sounds worth its own issue. Please submit one with a reproducible example and details, like which kind of source having this issue or the exact package on crates.io.

[BatmanAoD]

@weihanglo The oldness of that issue is why I asked what the current expected behavior is.

As an example, take nalgebra-macros: cargo add nalgebra-macros; cargo check results in ~/.cargo/registry/src/xxxxx/nalgebra-macros-0.2.2/LICENSE containing the text ../LICENSE. If this is not the expected behavior, I'll go ahead and open a new issue.

[weihanglo]

I believe that's because the file in the uploaded tarball has literally such the content: https://static.crates.io/crates/nalgebra-macros/0.2.2/download.

Without double-checking source code, from what I have in my mind, symlinks are copied and duplicated during cargo packageing. I've cloned dimforge/nalgebra@48c8f6a
and run cargo +1.83.0 package -p nalgebra-macros and the content of LICENSE is the current license text.

Perhaps there are something wrong with their upload process, or some old cargoes odd behavior?

[weihanglo]

Anyway, I'll mark our comments off-topic. Let's open a new issue if needed. Thank you!

[epage]

We discussed this in today's meeting.

The underlying need is "include license files in .crate"

license-file is automatically copied over on cargo package and cargo new will inherit the field if in the workspace but license-file is intended for custom licenses and is discouraged (via warning) to mix with license

That behavior around license-file is often confusing to users (e.g. #9908) and there are improvements we should probably make around it.

For example, what if we had

license = "MIT OR Apache-2.0"
license-file = { MIT = "LICENSE-MIT", "Apache-2.0" = "LICENSE-APACHE" }

(with us doing extra serde work to provide a good error message for Apache-2.0 which would be ["Apache-2", "0"])

See also #8537 (comment) for ideas that get into changes to SPDX

So what does that mean in the short-term? Most things we do with cargo new are two-way doors so we could do this now and then pivot in the future.

• There was some hesitance about blindly copying files from the workspace root. It could be a thing we exclusively do if we also inherit workspace.package.license.
• While I use symlinks, Windows users can have enough problems with them we might not want to push out a general policy that uses them
• If we instead copy files, that could cause problems for people who put copyright statements in the license files (either listing copyright holders or copyright years) as they would then need to copy these throughout their repo.

We could create a generalized solution, like

• package.extra-files for publishing but then we need to map where files come from to where they go
• workspace.new-files for saying what files to copy but then we are getting even more into templating which we're hesitant on.

For me, it seems like a short-term solution is not worth it. Hopefully someone (@joshtriplett ?) takes on a long-term solution.