search

sstadick / cargo-bundle-licenses

Generate a THIRDPARTY file with all licenses in a cargo project.
Apache License 2.0
86 stars 6 forks source link

Removing/ignoring CARGO_HOME prefix? #8

Closed morrisonlevi closed 1 year ago

morrisonlevi commented 2 years ago

I'm using cargo-bundle-license in my CI to alert me when licenses have changed. However, the license file checker is sensitive to the $CARGO_HOME variable, so if I commit the license bundle on one system (my local machine) and check for compliance on another (the CI machines), then I'm likely to get nonsense messages, like this:

[2022-03-16T13:17:41Z ERROR bundle_licenses_lib::bundle] Previous ring:0.16.20 does not match new ring:0.16.20

All that's different is license file path e.g.

-    license: License specified in file (/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/LICENSE)
+    license: License specified in file (/go/src/github.com/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/LICENSE)

As far as I can tell, this isn't a useful thing. Maybe something like $CARGO_HOME/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/LICENSE can be stored instead, with the variable not expanded?

sstadick commented 2 years ago

Thanks for making an issue!

I think that totally makes sense to replace the $CARGO_HOME path in the License::File with a "normalized" path that has a better chance at being the same across machines (i.e. doing what you say and literally putting the un-expanded variable in path).

I'm working on a fix for this, it may not be a super fast turnaround, but hopefully a new version in a week or so as I find time.

sstadick commented 2 years ago

The one-week turnaround obviously didn't happen! This will still make it in a release and is a good idea. If someone gets a PR in before me that would be awesome 👍

sstadick commented 1 year ago

@Skgland @morrisonlevi see v1.0.0 release (which is building now)

sstadick commented 1 year ago

I was overconfident in my CI - see v1.0.1