Error message should be more informative when build fails due to missing vendored dependencies

[bholley]

We use 'replace-with' in mozilla-central [1] to force all dependencies to be vendored. However, if somebody does |cargo update| and then does not re-vendor the sources, the provided error message is pretty opaque:

0:10.34 error: no matching version = 1.0.23 found for package libz-sys
0:10.34 location searched: registry https://github.com/rust-lang/crates.io-index
0:10.34 versions found: 1.0.16
0:10.34 required by package mozjs_sys v0.0.0 (file:///files/mozilla/mc/b/js/src)

It would be nice to inform the user that a replace-with is active for source.crates-io and that they may want to revendor. This bit @ekr today.

CC @alexcrichton @aturon

[1] https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/.cargo/config.in#6

[ekr]

Thanks Bobby. FWIW, I wasn't trying to revendor or anything like that. Rather mach complained that I had too old a version of cargo and I had been using apt recently and thought "hey, cargo update might fix this", and obviously it didn't!

[alexcrichton]

Ah yes definitely something we should improve! The error message is generated here for now, and it's not currently trivial to reach into the directory source to pull out a good error message (that source is buried within the package registry in Cargo terms), but I think we could massage things to get a better error message out of this.

@ekr to confirm though, it sounds like you ran a cargo update to fix a problem, but it didnt end up fixing the problem and gave the error message above? (which definitely seems like it could be confusing if it didn't fix the original problem!)

cc @Eh2406, you may also have thoughts on this as well!

[ekr]

@alexcrichton. The order of things was

1. mach complained about cargo being too old
2. ran cargo update
3. realized cargo update isn't what I wanted and then updated rust
4. Ran mach build
5. Got the error above.

[alexcrichton]

Ok cool, makes sense, thanks!

[alexcrichton]

Ok I've tried to improve the state of affairs in #6112 here

@ekr if you have a moment mind taking a look at the new error message and seeing if that would have been less confusing in your case?

[ekr]

I'm sorry to say that I don't think this would have been clear to me. In particular, I don't think I would have realized that it was I who had messed up the local state rather than that it was some kind of problem with the build (which is what I initially thought)

…

-Ekr

On Sat, Sep 29, 2018 at 2:39 PM Alex Crichton ***@***.***> wrote: Ok I've tried to improve the state of affairs in #6112 <#6112> here @ekr <https://github.com/ekr> if you have a moment mind taking a look at the new error message <https://github.com/rust-lang/cargo/blob/fc34ba1252513eb4fb3d969696ac03cd17cd7ef2/tests/testsuite/directory.rs#L715-L721> and seeing if that would have been less confusing in your case? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oX7kNJ5hCxDiwzlaaF4-MwksQ67Pks5uf-iRgaJpZM4W_7TR> .

[bholley]

So IIUC, the last line of the actual error message ekr would have seen would be:

location searched: directory source /path/to/mc/third_party/rust (which is replacing registry crates.io)

Which still might not be enough, but is a bit more specific than the regexp in the test linked above.

Perhaps in the case where we write the "which is replacing registry" bit, we can add something like:

(Perhaps you added a dependency on a crate from crates.io without adding a corresponding crate to /path/to/mc/third_party/rust ?)

Or something like that. Thoughts?

[ekr]

I'm starting to wonder if it wouldn't just be better to have mach check for this occurrence. Is that something we could do?

…

On Sat, Sep 29, 2018 at 3:08 PM Bobby Holley ***@***.***> wrote: So IIUC, the last line of the actual error message ekr would have seen would be: location searched: directory source /path/to/mc/third_party/rust (which is replacing registry crates.io) Which still might not be enough, but is a bit more specific than the regexp in the test linked above. Perhaps in the case where we write the "which is replacing registry" bit, we can add something like: (Perhaps you added a dependency on a crate from crates.io without adding a corresponding crate to /path/to/mc/third_party/rust ?) Or something like that. Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oWVOIVUXfvAE1bFV2mQ6iU8b0zc7ks5uf-9UgaJpZM4W_7TR> .

[bholley]

Assuming by 'mach' you really mean 'the build system' (to which |mach build| delegates), that seems like it could plausibly work. I don't have a good sense of exactly how it'd be done but it seems reasonable.

Maybe a good path forward here is for Alex to land whatever more-informative error messaging he feels is reasonable to put in Cargo, and then we can file a bug and ask the build people to detect that message, and supplement it with an additional message specific to our setup (suggesting |mach vendor rust|)?

[ekr]

n Sat, Sep 29, 2018 at 3:17 PM Bobby Holley <notifications@github.com> wrote:

Assuming by 'mach' you really mean 'the build system' (to which |mach build| delegates), that seems like it could plausibly work. I don't have a good sense of exactly how it'd be done but it seems reasonable.

Actually, what I was sort of thinking is that mach itself would keep track of the expected state of the files (or look to see if it differed from what is in git/hg) and throw an error. I wouldn't bother to put this in the build system.

…

[bholley]

Sure, we can see what the build folks think. We can probably take that discussion to a Bugzilla bug.

In the mean time, I think we're probably good on the Cargo side with the new messages, though the additional parenthetical hint I suggested above could be helpful in this case if Alex thinks it's generally appropriate. Thanks!

[alexcrichton]

@bholley that all sounds good to me! I'll see if I can fit in a message like that