Snowflake crate issues

[mfarrugi]

I ran into a couple of issues putting together https://github.com/mfarrugi/cargo-raze-example-stdx/blob/master/cargo/Cargo.toml, though it ultimately worked. The issues are generally mild, but inform on some of the edge case chicanery of build.rs scripts.

1. mime_guess.2.0.0-alpha.3 build script is not correct, since it is trying to generate sources in the source directory. (Work around is running build twice, or committing the generated code)

2. Unicase output dirs appear to compete w/ each other. (Workaround is skipping the build scripts)

3. reqwest requires CARGO_PKG_NAME and CARGO_PKG_VERSION variables when building -- this is more of an issue for rules_rust. (Workaround here was patching the usage, since there was only one).

[acmcarther]

I'd really like to set up some smoke tests that generate plans for a set of crates, and then attempt to bazel build those crates. I haven't done it yet, as the support for Bazel in TravisCI is poor, and I haven't set up my own ConcourseCI instance yet (where I'd be able to do whatever I want)...

Thanks for this list -- I'll definitely be testing against these crates whenever i get that infra set up (and I'll be looking into seeing if we can add options to the Cargo.toml to make handling these cases easier).

[acmcarther]

Revisiting this issue.

Item 1:

I believe that build script substitutions will not be uncommon as more crates are evaluated. My nascent best practice for this I think will be to suggest users maintain a cargo_overrides sibling directory (fs particulars unimportant), which contains curated full crates, build scripts, or resources. Then a combination of additional_deps + skipped_deps can be used to tune generated crates. This isn't perfect, but it should work at small scale. As an aside, this point implies that it should not be difficult to produce a build script genrule -- without copy and pasting the huge ball of cruft that raze current generates. Moving the complexity into a simple py_binary should help here.

Item 3:

I don't have a good solution for this yet. As you've noted, patching the source is a possibility. I submitted a patch to bindgen for their own instance of this problem. Unfortunately, fixing this requires a rules_rust change (as you may already be aware).

As noted in comment 2, I really would like to automate the discovery of these issues, and I don't think it would be hard to compile the top N crates to discover the bigger issues.