From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <20170103125409.095aea4e@scratchpost.org> References: <20170103024407.6928-1-dannym@scratchpost.org> <20170103025103.8147-1-dannym@scratchpost.org> <20170103050157.223af717@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cONfY-0005aC-H1 for guix-devel@gnu.org; Tue, 03 Jan 2017 06:54:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cONfV-0004xr-FT for guix-devel@gnu.org; Tue, 03 Jan 2017 06:54:20 -0500 Received: from dd1012.kasserver.com ([85.13.128.8]:40262) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cONfV-0004xM-95 for guix-devel@gnu.org; Tue, 03 Jan 2017 06:54:17 -0500 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: David Craven Cc: guix-devel Hi David, On Tue, 3 Jan 2017 12:08:56 +0100 David Craven 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