From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id EGu+FmGIVWfIwgAAe85BDQ:P1 (envelope-from ) for ; Sun, 08 Dec 2024 11:52:01 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id EGu+FmGIVWfIwgAAe85BDQ (envelope-from ) for ; Sun, 08 Dec 2024 12:52:01 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=mARk+e83; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=libre.brussels ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1733658721; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=oFiNx6hVxPHz/o0OWDvGUGSsCWf85XA4jPF1GwyP4Ls=; b=g/HPbtam002YpRVcelprIe19NOc4REkt85erhVmnIjyXfYfmmpqvg8bPX9JQKMRTh/aS7j wMDGOndX1Hq7cbDnD46m51mvg/ZTWEYvb3yUstJj3AiQ/KwQhFg3PoPdKkypgJINILubdZ 7A2a4olkn3XBeNbXY2mv98oLgADA3T67CiE9nbKCAV33HGNIJTlHI3PzEmnIY6w0KR9jOj EZvvNpndXEHUfohn6FWSsL6t5fO22qXuBGYDmNX/jgcu947s8B6hSqib/rMKhw/oEzvSfx nY3FapR/4VxBDU/u9MxPbFQ3mI/afMBUw7evkBNmK1I2dTL+wzmsePnLnzrWKg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=mARk+e83; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=libre.brussels ARC-Seal: i=1; s=key1; d=yhetil.org; t=1733658721; a=rsa-sha256; cv=none; b=kf3OpR/1xO7pNyVs8Z6H8YUIlNtP6TZ4qcvtFPfCHBPWQ9GTl8rA/DsdywFCaKMaXCWyP2 O951fjzt2iFCDcgvWzquOE3WbXpL5xPxUTVshdUgP4ztHNRfJZhEKje4FW+YQCS22SxPMp QHNLC42ri5YEnYbjDr8hHb4gPpoXjw2gTXJu4+Lnq667UvO9UtHdRI7IpEgcuKIgOA3bbK pCtZS3hi9dvLZJM9qm2M3UAR2bQfHJfE5zh29tORoPnJzAZJf9MngHzEwx5p0y3GdLMhn7 m2KF824JjqhxXUi6VHvrmgbENOsKFfhJ4g1XEbSMW+7AmX1YJBGFFEsX6EOIdw== 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 3E9B04495B for ; Sun, 08 Dec 2024 12:52:00 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKFog-0003Mw-38; Sun, 08 Dec 2024 06:51:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKFoc-0003Mh-P8 for guix-devel@gnu.org; Sun, 08 Dec 2024 06:51:11 -0500 Received: from libre.brussels ([144.76.234.112]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKFoZ-0001qS-DT for guix-devel@gnu.org; Sun, 08 Dec 2024 06:51:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libre.brussels; s=mail; t=1733658661; bh=O5oea74I0F3JbmGRdsxEdCvAijk2/3AKtEqqfVXarGk=; h=Date:From:To:Subject:In-Reply-To:References:From; b=mARk+e83NmOhpZYyqReymw+g7qLOHxLBWpjo9sToK1JdFWK/oAVKNEprx3gCBq4oq cXHo0UVX0AToociRgaP19hXKXrMgwJ+TUYCL8jdkeq3orUVt4BMkOU0OP1rdETuv8+ sRq70hzycBSPUrRJm5/yDmi0O1rxAtzL1OLDa5AE= MIME-Version: 1.0 Date: Sun, 08 Dec 2024 11:51:01 +0000 From: indieterminacy To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , Ricardo Wurmus , guix-devel , Nicolas Graves Subject: Re: How to build Rust packages In-Reply-To: References: <87ldwy3uhr.fsf@inria.fr> <87o71tanwy.fsf@elephly.net> <87h67iv3nw.fsf_-_@inria.fr> Message-ID: X-Sender: indieterminacy@libre.brussels Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=144.76.234.112; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -5.32 X-Spam-Score: -5.32 X-Migadu-Queue-Id: 3E9B04495B X-TUID: fd53xL6JtrfR I should point out that I am packaging Scryer-Prolog, which uses Rust in its underbelly. As it stands, the divergences of crate versioning means that my package definition is nearly 60k LOC and Ive had to validate over 1.1k packages already. Naturally, some of these are duplicates of Guix package definitions, as well as updates. Nethertheless, I have a considerable bounty to unfurl once I reach maturity with this initiative. It will be a job in itself to provide the actual patches and push them to you so there will be some lags (weeks even). I should brush up on patch workflow in Emacs-Magit for flow. Naturally, there are some edge cases regarding what Im packaging but Ive been trying to minimize attention. Once I hit a wall should I query at the Guix-Help ML or for such a large package environment should I use this ML? I suppose a link to a scm file on a git-forge (with commit) is apt rather than providing a file? Oh, my TXR parsing of Guix packages is ticking along which I am doing this project! I reckon it can be adapted nicely for a comparative method between different config files. On 2024-12-08 09:20, Efraim Flashner wrote: > On Thu, Dec 05, 2024 at 11:13:07AM +0100, Ludovic Courtès wrote: >> Hello, >> >> Efraim Flashner skribis: >> >> > I still have a copy of the code on my machine but unfortunately it no >> > longer builds due to the constant churn of rust packages. >> > >> > One thing I remember explicitly about it was that building end packages >> > was faster than the current method, and that was before taking into >> > account reusing build artifacts. >> > >> > https://notabug.org/maximed/cargoless-rust-experiments >> >> Neat. >> >> > Another idea which I'm not in love with is what Debian does. They grab >> > all of the sources into one build environment and then build everything. >> > It simplifies the dependency management of the sources but for us it >> > would make it so that we can't touch anything in rust without causing a >> > full rebuild of everything. >> >> I believe this is also what Nixpkgs does, as discussed in this thread: >> >> https://toot.aquilenet.fr/@civodul/113532478383900515 > > I'm pretty sure they parse the Cargo.lock file and download the crates > at build time. > >> I’m not a fan either. But I think one of the main criteria here >> should >> be long-term maintainability, which is influenced by internal design >> issues and by how we design our relation with the external packaging >> tool. >> >> By internal issues I mean things like #:cargo-inputs instead of >> regular >> inputs, which makes the whole thing hard to maintain and causes >> friction. (See .) >> >> As for the relation with Cargo and crates.io, the question is should >> we >> map packages one-to-one? Is it worth it? If the answer is yes, do we >> have the tools to maintain it in the long run. > > As it stands now the package name is effectively prepending 'rust-' and > switching any underscores to dashes. Most of the actual packaging work > is making sure the cargo-inputs from patches correctly match the > versions in Cargo.toml, checking the metadata (license, home-page, > synopsis/description), and seeing if any code needs to be removed (such > as from *-sys packages). If there are any "real" packages then they > normally don't have the rust- prefix. > > I don't want to go and parse Cargo.lock, automagically generate > packages > based on that, and then download those as cargo-inputs for packages. > Not > only does that potentially pull in old versions of libraries which may > have necessary updates or patches, it doesn't check them for license > data or vendored C libraries. > > I also don't want to keep a collection of "difficult" crates that need > a > human touch and have everything else be autogenerated at package build > time. > > I am jealous of the cran updater and all the work Rekado has put into > making it work well, and I know I need to actually fix a bunch of stuff > with the crates. An updater and also the etc/committer.scm file. > There > are too many crates to actually package them all, so that wouldn't be > something workable to automatically package all of them. > > I have a script that goes through the crates and lists how many > dependencies there are per file, and I have used it in the past to > remove unused crates. I have also come back and added them back in > when > something else needed them. > > My workflow is I work on 20-50 crates at once, and when they all build > correctly I then break them into the appropriate number of commits. > > I'm not sure where to go from here. I don't even remember if the > antioxidant build system correctly shows the dependency path between > crates, which IMO is one of the big things missing now.