[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WIP patch: build-system: cargo: Make lots and lots of rust packages
From: |
Danny Milosavljevic |
Subject: |
Re: WIP patch: build-system: cargo: Make lots and lots of rust packages work |
Date: |
Tue, 3 Jan 2017 12:54:09 +0100 |
Hi David,
On Tue, 3 Jan 2017 12:08:56 +0100
David Craven <address@hidden> 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