From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0r.migadu.com with LMTPS id +B4qI4kdjWDBGwEALuJCtg (envelope-from ) for ; Sat, 01 May 2021 11:21:13 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id MATBHokdjWBdfwAAbx9fmQ (envelope-from ) for ; Sat, 01 May 2021 09:21:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EBB9BE7FE for ; Sat, 1 May 2021 11:21:12 +0200 (CEST) Received: from localhost ([::1]:39914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcloF-0004hE-Rb for larch@yhetil.org; Sat, 01 May 2021 05:21:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lclo5-0004gl-JJ for guix-devel@gnu.org; Sat, 01 May 2021 05:21:01 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:37320) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lclo3-0007ro-1e; Sat, 01 May 2021 05:21:01 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4FXNyH2nrmz1qskB; Sat, 1 May 2021 11:20:55 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4FXNyH2Vq6z1r0h0; Sat, 1 May 2021 11:20:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id oaNdFRXukAP2; Sat, 1 May 2021 11:20:53 +0200 (CEST) Received: from hermia.goebel-consult.de (ppp-188-174-62-36.dynamic.mnet-online.de [188.174.62.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Sat, 1 May 2021 11:20:53 +0200 (CEST) Received: from lenashee.goebel-consult.de (lenashee.goebel-consult.de [192.168.110.2]) by hermia.goebel-consult.de (Postfix) with ESMTP id 3B42960213; Sat, 1 May 2021 11:23:12 +0200 (CEST) From: Hartmut Goebel To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= References: <87eeesgif0.fsf@gnu.org> Organization: crazy-compilers.com Subject: Re: #:cargo-inputs don't honor --with-input Message-ID: <1ea7cf3d-b75f-c47a-9730-406ecc610e7c@crazy-compilers.com> Date: Sat, 1 May 2021 11:20:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <87eeesgif0.fsf@gnu.org> Content-Type: multipart/alternative; boundary="------------D93B7A5FE5B4E9A06EE7D54D" Content-Language: en-US Received-SPF: none client-ip=212.18.0.9; envelope-from=h.goebel@crazy-compilers.com; helo=mail-out.m-online.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel , Ivan Petkov Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619860873; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=cHPqF4/wQTp6oJUOIGD5t5fnQSaVj0qrud8cHsGc+Fo=; b=t+WnjyOzTd9r6f1zqKYUF9EtFp8eGXf8OxNqqTuabe788IM/Ca4Wyfj5VxUqthkjR6469N Mra/h6adPGUPBPzyvM4uMzQawk6D6Z8L5GDHLBwaHtD85oT8pEqaLq1I+9Q1RR4aTOkJf+ BbzZKrphczE+2klvnm4c7Hqdt9fCpY+XqkPwXq/sFPJsR9gaZInstlnK4XN80WB3U+LSbl 2A891bWREo/2QTVmTMw3MiIBW9jgSFp1Bi+oBm9O0yma5Th81m2NwyHu38VBSnSF/Z2B7v 4MRiMJ0LCSYSnwaj+qnKv1cCK4LWXyQNyyDR3xWqmNqO+VZzA6M8nYC9z6u5bw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619860873; a=rsa-sha256; cv=none; b=PyNVFwB0jy32Ngv1gFFC6H+EKTP/VNJUIcTiU6n9YKguLvzHyTE9uXmou4NDrRjxu7EW4P VW8eisPd041O3WkyQZS5cEbjAUykbr2KXJf/fqvsXEYd35rcEKmkRWkWHBDvIUNWSBgL2l GHWCzqHW9sucp3qFwK2x9nBxk2iAz0bltX5hdtTiw9iHbWPmScVBejYPhkpsUv2fKO2Oh7 V2t8PmJiqXcSL+A6w6AOmH5SyHryG+hugviyKIaAGZL4jLZbm/p2tl+QGRkaWdev2RsOm9 rf0qbFerKcEKBuqV9BRfxC4KRbklgQZdj0zUoamGfk+QCairuAmwBb8nKJCOLQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -2.46 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: EBB9BE7FE X-Spam-Score: -2.46 X-Migadu-Scanner: scn0.migadu.com X-TUID: ppXPdANh3mYZ This is a multi-part message in MIME format. --------------D93B7A5FE5B4E9A06EE7D54D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ludo, Am 30.04.21 um 12:45 schrieb Ludovic Court=C3=A8s: > Uh. More generally, Rust packages kinda create a =E2=80=9Cshadow depen= dency > graph=E2=80=9D via #:cargo-inputs & co., which breaks all the tools tha= t are > unaware of it. It was discussed several times on this list, and > apparently it=E2=80=99s unfortunately unavoidable at this time. :-/ Maybe we can get rid of #:cargo-inputs at least: guix/build-system/cargo.scm says: "Although cargo does not permit cyclic = dependencies between crates, however, it permits cycles to occur via dev-dependencies" So we could change #:cargo-inputs into normal inputs and get at least=20 part of the dependencies right. I'm aware of the "special treatment" of cargo-inputs. Anyhow we could=20 apply the following changes to the cargo build-system: * The cargo build-system copies the "pre-built crate" (more on this below) into a new output called "rlib" or "crate". There already is a phase "packaging" which only needs to be changed to use the other output. * All of today's #:cargo-inputs will be changed into normal inputs using the "rlib/crate" output. (To avoid duplicate assoc-rec keys we might need to change the name/keys, but this should be a minor issue.= ) * If required, the cargo build-system can easily identify former #:cargo-inputs=C2=A0 by being inputs from a "rlib/crate" output. Benefits up to here: * The dependency graph would be much more complete - although "#:cargo-development-inputs" would still be missing. * Package transformation options would work -again except for "#:cargo-development-inputs". * If(!) we actually manage to make cargo pick "pre-built" crates, package definition will already be adjusted to use them. |Drawbacks up to here:| * ||Since the "packaging" phase copies the source, there is not much benefit in having a "rlib/crate" output yet. Actually, when a "rlib/crate" output needs to be build, the user will end up with two copies of the source (one from the git-checkout, one from packaging) About "pre-built" crate: Given the many possible ways to build crates=20 (e.g. switching on and off "features", different crate types), we might=20 never be able to provide pre-built packages for all cases. Thus we might = end up always providing the source, even if we manage to make cargo pick = of pre-built artifacts. About the output name: Rust has a notion of "rlib" (a specialized .a=20 file), which seems to be the pre-built artifacts we are seeking. Thus=20 the proposed name. WDYT? --=20 Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | --------------D93B7A5FE5B4E9A06EE7D54D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Ludo,

Am 30.04.21 um 12:45 schrieb Ludovic Courtès:

Uh.  More generally, Rust packages kinda create a “shadow dependency
graph” via #:cargo-inputs & co., which breaks all the tools that are
unaware of it.  It was discussed several times on this list, and
apparently it’s unfortunately unavoidable at this time.  :-/

Maybe we can get rid of #:cargo-inputs at least:

guix/build-system/cargo.scm says: "Although cargo does not permit cyclic dependencies between crates,
however, it permits cycles to occur via dev-dependencies"

So we could change #:cargo-inputs into normal inputs and get at least part of the dependencies right.

I'm aware of the "special treatment" of cargo-inputs. Anyhow we could apply the following changes to the cargo build-system:

  • The cargo build-system copies the "pre-built crate" (more on this below) into a new output called "rlib" or "crate". There already is a phase "packaging" which only needs to be changed to use the other output.

  • All of today's #:cargo-inputs will be changed into normal inputs using the "rlib/crate" output. (To avoid duplicate assoc-rec keys we might need to change the name/keys, but this should be a minor issue.)

  • If required, the cargo build-system can easily identify former #:cargo-inputs  by being inputs from a "rlib/crate" output.

Benefits up to here:

  • The dependency graph would be much more complete - although "#:cargo-development-inputs" would still be missing.
  • Package transformation options would work -again except for "#:cargo-development-inputs".
  • If(!) we actually manage to make cargo pick "pre-built" crates, package definition will already be adjusted to use them.

Drawbacks up to here:

  • Since the "packaging" phase copies the source, there is not much benefit in having a "rlib/crate" output yet. Actually, when a "rlib/crate" output needs to be build, the user will end up with two copies of the source (one from the git-checkout, one from packaging)

About "pre-built" crate: Given the many possible ways to build crates (e.g. switching on and off "features", different crate types), we might never be able to provide pre-built packages for all cases. Thus we might end up always providing the source, even if we manage to make cargo pick of pre-built artifacts.

About the output name: Rust has a notion of "rlib" (a specialized .a file), which seems to be the pre-built artifacts we are seeking. Thus the proposed name.

WDYT?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |
--------------D93B7A5FE5B4E9A06EE7D54D--