guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]