Hi David, On Tue, 3 Jan 2017 12:08:56 +0100 David Craven <da...@craven.ch> wrote:
> Can you elaborate on why you think it's a bad idea to separate the > source from the binaries into different outputs? Huh? I think it's a good idea. It just doesn't work yet and I didn't find out why :) > I see that you are trying to mimic what cargo vendor does. Cool proof > of concept and nice solution to the computing sha256 hashes on the > build side. Yeah. I thought they can't exactly replace all the bundled files in all the repos (written by anyone) if they ever changed the file format - so it's there to stay "forever". There's no downside I can see. That said, we can also do it via cargo vendor if it's easy. But it's not really required - we can always just change it to that if it ever breaks. > The question is if this is the best approach. I was thinking of trying > [0] first and see how that works for the build system use case. The > cargo package example using vendoring is intended to be a temporary > solution, and I'm not sure we have finished exploring the "design > space" yet. > > [0] https://github.com/alexcrichton/cargo-local-registry That's interesting too! We can try both. My patch is just a WIP patch of something that works. We should explore the other alternatives, too. But about the current approach in master, I talked to Alex Crichton [1], he said that the "replace" approach won't work without a registry because it tries to replace crates by the exact same version and what you specify for "replace" is just an API version. I think by then you can just go all the way to a custom registry and dispense of the "replace". [1] https://github.com/rust-lang/cargo/issues/3476
