include license and readme file in crate source of nalgebra-macros
Hi. i am in the proccess of packaging nalgebra-macros in fedora and they would like to have the license and the readme include in the crate source.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text
I don't know if this issue is fixed for Fedora, but I think it still persists for cargo installs.
The tarball for nalgebra-macros (as of the latestversion, 0.2.2) does include a LICENSE file, but rather than containing the license text, it contains the symlink path, ../LICENSE. This can be verified either by direct download or using cargo:
cargo add nalgebra-macros
cargo check
cat ~/.cargo/registry/src/xxxxx/nalgebra-macros-0.2.2/LICENSE
It may be that this will be automatically fixed if the next release is created with a recent-enough version of cargo; @weihanglo tried cargo package and found that it properly expanded the license text: https://github.com/rust-lang/cargo/issues/13328#issuecomment-2526886694
rather than containing the license text, it contains the symlink path, ../LICENSE
This is often a problem when running cargo package / cargo publish on an OS that does not support symbolic links (i.e. Windows), which might explain why it works for some people and doesn't for others.
@decathorpe Do you know how nalgebra's cargo-publish CI is set up? I would be surprised if it's run on Windows for some reason. (Also, I'm kind of surprised to hear that cargo publish doesn't support symbolic links, since you can configure git to use symbolic links in Windows.)
I don't know - though it looks like publishing to crates.io isn't automated in CI.
(Also, I'm kind of surprised to hear that cargo publish doesn't support symbolic links, since you can configure git to use symbolic links in Windows.)
The problem isn't that cargo publish doesn't support symbolic links - the problem is that support for symbolic links needs to be configured on both the Windows side and in git for them to work correctly for this use case AFAIK - and its off by default in both places.