Skip to content

The wit-bindgen-rt crate does not ship with a README.md or a LICENSE file #1170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ephemeralriggs opened this issue Feb 21, 2025 · 9 comments

Comments

@ephemeralriggs
Copy link
Contributor

The current version (0.39.0) as of this writing of wit-bindgen-rt on crates.io does not come with a README.md or LICENSE file.

While the former is more of an inconvenience, the missing of a LICENSE file is an issue for projects that auto-check for licence compatibility during build. It would be helpful of those files could be added to the crate.

@alexcrichton
Copy link
Member

A README was added in #1162, and for LICENSE can you use the license field of Cargo.toml?

@ephemeralriggs
Copy link
Contributor Author

It would be the first time that we are doing this for our projects, since every other crate we use ships a LICENSE file. So naturally I would prefer to avoid special handling just for one single crate. May I ask what is special about wit-bindgen-rt that the LICENSE files are included in the source code repository but are not included in the release on crates.io?

@alexcrichton
Copy link
Member

The BA has a number of repos, such as this, https://github.com/bytecodealliance/wasm-tools, and https://github.com/bytecodealliance/wasmtime, which all are a workspace of many crates. Instead of copying files all over the workspace the license files are only present at the root and all crates are annotated with that license. I don't know how to manage a workspace of many crates without having many copies of a license.

@erickt
Copy link

erickt commented Mar 12, 2025

Hi Alex! Long time no see.

The two ways to take care of this that we know of is to either use license-file in the workspace and crate packages, or to use symlinks, such as https://github.com/serde-rs/serde/tree/master/serde_derive. My personal preference is symlinks since it still allows for SPDX expressions in the Cargo.toml. If that'd be appropriate, we could put together a PR for it if you'd like.

@alexcrichton
Copy link
Member

Hey! Too long time with no see!

Agreed I'd want to stick to license given that we also have three license files instead of one to stick in license-file. Do you know how the symlink bits work on Windows? I always assumed that solution relied on developers basically not working on Windows or otherwise having turned on that setting of "allow symlinks"

@erickt
Copy link

erickt commented Mar 13, 2025

What a wonderful question. I checked on a windows machine, and it does do the wrong thing in this case, the LICENSE-APACHE file just contains ../LICENSE-APACHE, rather than the copied contents. However cargo package does warn that this appears to be the case:

% cargo package
warning: found symbolic links that may be checked out as regular files for git repo at `C:/Users/erickt/Projects/serde/`
This might cause the `.crate` file to include incorrect or incomplete files
note: to avoid this, set the Git config `core.symlinks` to `true`
And on Windows, enable the Developer Mode to support symlinks

Following those two suggestions gets it to properly build the package though. As far as I can tell this only impacts the person running cargo package or cargo publish, unless of course you use symlinks for files needed by other commands like cargo build.

The one caveat is if you do run git config set core.symlinks true without turning on developer mode, you'll get this error on git checkout:

error: unable to create symlink serde_derive/LICENSE-APACHE: Permission denied

Git unfortunately doesn't guide users to enable developer mode though, so it could be confusing for them.

@alexcrichton
Copy link
Member

Oh thanks for investigating that! That all seems pretty reasonable to me honestly. For publication we auto-publish from CI on Linux so I'm not worried about that, so the only other downside is clones with core.symlinks true, but given that it sounds like that's non-default folks presumably know what they're getting into with that if they don't have developer mode turned on, so that seems like a reasonable tradeoff.

If that'd be appropriate, we could put together a PR for it if you'd like.

If you're still up for it i wouldn't mind taking you up on this offer. A PR to add symlinks to all crates pointing back to the root seems like it should be reasonable!

@ephemeralriggs
Copy link
Contributor Author

If you're still up for it i wouldn't mind taking you up on this offer. A PR to add symlinks to all crates pointing back to the root seems like it should be reasonable!

Thank you so much! This is great! 👍

@alexcrichton
Copy link
Member

Thanks again for the PR and help figuring this out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants