Skip to content
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

Removing/ignoring CARGO_HOME prefix? #8

Closed
morrisonlevi opened this issue Mar 16, 2022 · 4 comments
Closed

Removing/ignoring CARGO_HOME prefix? #8

morrisonlevi opened this issue Mar 16, 2022 · 4 comments
Labels
good first issue Good for newcomers

Comments

@morrisonlevi
Copy link

morrisonlevi commented Mar 16, 2022

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/git.luolix.top-1ecc6299db9ec823/ring-0.16.20/LICENSE)
+    license: License specified in file (/go/src/github.com/.cargo/registry/src/git.luolix.top-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/git.luolix.top-1ecc6299db9ec823/ring-0.16.20/LICENSE can be stored instead, with the variable not expanded?

@sstadick
Copy link
Owner

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 sstadick added the good first issue Good for newcomers label May 9, 2022
@sstadick
Copy link
Owner

sstadick commented May 9, 2022

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
Copy link
Owner

sstadick commented Oct 7, 2022

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

@sstadick sstadick closed this as completed Oct 7, 2022
@sstadick
Copy link
Owner

sstadick commented Oct 7, 2022

I was overconfident in my CI - see v1.0.1

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

No branches or pull requests

2 participants