License handler lock file issues

[alerque]

Graphite/tools/third-party-licenses/src/cargo.rs

Line 89 in d90a49a

.args(["about", "generate", "--format", "json", "--frozen"])

The --frozen argument here regularly trips up any attempts to build this app ... ironically I'm trying to make the build work properly offline, but fetching locked dependencies ahead of time does not work because whatever lock file this references is used in any top level fetch we seem to be able to do.

If there is some command we can run for a source preparation faze to correctly get what this is going to need so that the later build phase actually works with this argument, can that be documented somewhere? I didn't see it poking around anywhere yet.

[0HyperCube]

Hello, thanks for reporting @alerque. The cargo about command can be rather fragile. Its purpose is to generate license information for all crates used by a project, using the output of cargo metadata.

I was able to reproduce the issue by running the following commands in the root of the repository:

rm -rf ~/.cargo/registry # Location of cargo registry cache
cargo fetch --locked --target host-tuple
cargo metadata --format-version 1 --frozen --all-features # This command is executed internally by cargo about

Note that only crates for the host target are downloaded by cargo fetch. For example this excludes windows specific creates if compiling on unix. However the cargo metadata command with no additional options will try and download all crates (even if not used for the current host).

A simple way to fix would be to download all the crates for all of the targets by not specifying the target for the fetch command:

cargo fetch --locked

[alerque]

Well now that's interesting. Thanks for running that down! If that's the trouble then definitely keeping the --frozen argument is the right thing to do. I'll add some code comments about why we're fetching for all targets. I don't know if there is any appropriate place to note this for other potential packagers or if searching and finding this issue or Arch sources will be the way some other poor soul would discover it ... but thanks again for the diagnosis.