From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id MPl+ETZx8GWLXwAA62LTzQ:P1 (envelope-from ) for ; Tue, 12 Mar 2024 16:13:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id MPl+ETZx8GWLXwAA62LTzQ (envelope-from ) for ; Tue, 12 Mar 2024 16:13:58 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=TfUJZL4U; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710256438; 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:dkim-signature; bh=gd6ViGkTKh/ftWkHFfbDfbvuditjPdWbnK1MEvVxHqg=; b=XGpU/pxNiQNssuN4HLwaRDa0m6lXBTFhi5OgnUgSNaoDzd2idLqKjNe6jr6o2QxklW45vP kHw2Q3xa/8vwVnZ2YwFgYzLG9IMtLZzL921tiD6CwBk5Dac+5RHnHtwRtBmMEG+UO4HKYH wS8EclKqyNjB0OIVs5HGY3vrSVancr3RlqdHga2Sh+lPZZfzeUKp3sScfYG9K+uUog8j2W x18O8umeumfgzB5I+gCc99hUZ9JJNSnuGLR5EbMq9Jx8UB3DLDcqABY1GCM6gTE0zo6k4q cJGllDvxxoGStlghNewFwF5o1umEpNAR1pHZr8P6m0ufGyr+5dAli3In5kzJyw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710256438; a=rsa-sha256; cv=none; b=isTwl//UpStDivNSW6ovghxcg5qvwBELQJR+3pjUG9T1nUEO5zLUQyIhLZzTwrCRIbJIRO 8De8YM6On4cGBTuycckE/ug57fKm7AfEdbkLKvyaOhAX9IoXJOeddnHIvwIijwBCNG5Tjj qLtzj4Yhoyvz3TN4DMfr1gUhteOca6Gj74V5bdJ1IWcCK5omAjhtIFGZJTykn+y941jwu1 ERcf4iuQlljYiaJDeaT8PjlQ2Qs6Hj1e44S7Rf45yvX21UXJMHMTqY+8oEk89nPnTy9tHZ 0ifV2rhnsTXPYoaKKO5/+tmAm1eoya1pBJd8PTI/J45hdvTjKCAJDgIB/7WSMA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=TfUJZL4U; 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=none 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 D123F77F99 for ; Tue, 12 Mar 2024 16:13:57 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rk3om-0004ah-HX; Tue, 12 Mar 2024 11:13:28 -0400 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 1rk3oP-0004Qc-BG for guix-devel@gnu.org; Tue, 12 Mar 2024 11:13:06 -0400 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rk3oJ-0005rP-C8 for guix-devel@gnu.org; Tue, 12 Mar 2024 11:13:05 -0400 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4132ab0c302so15863545e9.3 for ; Tue, 12 Mar 2024 08:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710256377; x=1710861177; darn=gnu.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to :cc:subject:date:message-id:reply-to; bh=gd6ViGkTKh/ftWkHFfbDfbvuditjPdWbnK1MEvVxHqg=; b=TfUJZL4UAJQ5eBFE1BDUc5EGAmiphYtfgN3yqJu6B1h1lelLR9cgUvR6D7NBoki07n 630QKIib4eHl5o1kDsr0j5gDwGImm2Z21xuwD2qQMoeNc7Du0gzVZSlJu88ulm0r4oMP tIHJTbKTkFyL4xrPxJoDfMyhxsqkRpBF0aUhyUqFB91e/6CYn6ScXPjGomcBJFBekTB1 aASegRgDffeZE7HhcN4KxWZ05bu3HrLuW9jehhXqrjJ0X8x0TdQ+ha2XeFekYQ+31N6b X5ivZ5C9aPK9g9bOXLflILCDkKs0N0m6wQ8KMO+qsdXfuLq8OhWebQ5RxLl9oTMLRNdx fJfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710256377; x=1710861177; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gd6ViGkTKh/ftWkHFfbDfbvuditjPdWbnK1MEvVxHqg=; b=LT0rrlGTgHasxQPLdo51snE/nwR4ch1TfNSucHd1sONFd5AOSoHnpYInCQ1mUYQMnr 926bIOvvMQxMlrP0ICq98fF1GJiY0eic0qXHVqDDWGWltiVI/mngDrItXLcY06jb78/L xVlZFEBCm8927/psZqKWb02Ck2FtLyHDSnWJ5OjSelgFJBjXbAPys+TADtzDu+e3hQxx 8Y8dGaJy8dwerlIENQZGKn7xmvC4hhq50a3n1rTCwvzzmfeEX4pmcvHKYgz3M79Q17Xd TlPPIHblR5PO6bqNUe9ECJGWBSAUaNOGRYlDvyzlSo87jV4BRONWgl2X+fdYHZGXqaVB u8Sg== X-Gm-Message-State: AOJu0Yw4mSloh8GjxMYPMq4+Mj5VtWEh2RoE0gy9WWC4if+Hp3rUVpxh ocuvbFVMXnPmX+JMAk/DL5H4YpnVdfqzz3f2Au1KPpvO7GeEkpd9QKSbXXfrz08= X-Google-Smtp-Source: AGHT+IGHq0mF4aW/9OmYc6WWkz4xlsgK9GtbPvKyYe716tGVFyMLSsYZmarZrJlIJhIsIddUkPMeBw== X-Received: by 2002:a05:600c:3111:b0:413:160a:8112 with SMTP id g17-20020a05600c311100b00413160a8112mr8060034wmo.34.1710256376695; Tue, 12 Mar 2024 08:12:56 -0700 (PDT) Received: from localhost ([141.226.12.177]) by smtp.gmail.com with ESMTPSA id r4-20020a05600c35c400b004130c1dc29csm12680197wmq.22.2024.03.12.08.12.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Mar 2024 08:12:56 -0700 (PDT) Date: Tue, 12 Mar 2024 17:12:54 +0200 From: Efraim Flashner To: Jason Conroy Cc: guix-devel@gnu.org Subject: Re: rust-team branch merged Message-ID: Mail-Followup-To: Jason Conroy , guix-devel@gnu.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bHtwx6i4PlpJ2lyF" Content-Disposition: inline In-Reply-To: X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=efraim.flashner@gmail.com; helo=mail-wm1-x32d.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01 autolearn=no 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.89 X-Spam-Score: -6.89 X-Migadu-Queue-Id: D123F77F99 X-Migadu-Scanner: mx11.migadu.com X-TUID: ibu6Vz4re/1G --bHtwx6i4PlpJ2lyF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2024 at 11:48:53AM -0500, Jason Conroy wrote: > On Thu, Mar 7, 2024 at 3:08=E2=80=AFAM Efraim Flashner > wrote: >=20 > > The transitive dependencies getting pulled in automatically should work > > automatically if we ever finish the antioxidant-build-system. >=20 >=20 > Since you bring up antioxidant, I'm kind of curious whether that stalled > mainly due to shifts in contributor priorities, or due to significant > technical issues. More the first. I found that the actual build time was slightly faster using the antioxidant-build-system over the cargo-build-system but I wasn't in a position to take it up when the original author moved on to other things. > > Until then > > I've been experimenting by manually listing the other crates I've needed > > but in theory we could try to make `guix shell --development` pull in > > the needed crates. > > >=20 > I was considering another option that falls somewhere in between: since I= 'm > already building shells from manifest files, it should suffice to have a > Scheme utility function that calculates the transitive dependencies for a > given list of library packages. Similar logic seems to exist already in > `(guix build-system cargo)` but it's not exposed publicly. As interim > solutions go, what do you think about this one versus modifying `guix > shell`? Once you have something like that working it shouldn't be too hard to merge that into `guix shell`, assuming we go that route. > > > > I misread what you wrote as it was working. It's definitely something I > > want but wasn't ready to work on yet. > > > > > I took rust-rand as an example only because it does have some > > dependencies: > > > > > > $ cd $CARGO_PROJECT > > > $ cat Cargo.toml > > > [package] > > > name =3D "test_prog" > > > ... > > > [dependencies] > > > rand =3D "0.8.5" > > > > > > $ cargo build > > > Updating crates.io index > > > Downloaded cfg-if v1.0.0 > > > Downloaded rand_chacha v0.3.1 > > > Downloaded rand v0.8.5 > > > Downloaded ppv-lite86 v0.2.17 > > > Downloaded rand_core v0.6.4 > > > Downloaded getrandom v0.2.12 > > > Downloaded libc v0.2.153 > > > Downloaded 7 crates (932.0 KB) in 0.48s > > > Compiling libc v0.2.153 > > > Compiling cfg-if v1.0.0 > > > Compiling ppv-lite86 v0.2.17 > > > Compiling getrandom v0.2.12 > > > Compiling rand_core v0.6.4 > > > Compiling rand_chacha v0.3.1 > > > Compiling rand v0.8.5 > > > Compiling test_prog v0.1.0 (/home/...) > > > > > > > > > > Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 th= en > > > > you'd have both rand-0.*.crate files in the registry but only one of > > > > them would be listed in share/cargo/registry/index/ra/nd/rand. I ne= ed > > to > > > > adjust the generation of that file to combine multiple sources if t= hey > > > > exist, and sort them (I'm not sure it's necessary, but wouldn't be > > > > surprised if we hit undefined behaviour if they were listed multiple > > > > times or out of order). > > > > > > > > > I'm somewhat new to rust, but it appears that outside of Guix, the > > > local-only development workflow looks like this: > > > > > > $ cd $CARGO_PROJECT > > > $ mkdir $VENDOR > > > $ cargo vendor $VENDOR > > > > > > After downloading and unpacking all of the crates into $VENDOR, this = last > > > command instructs me to add the following in ~/cargo/config.toml. > > > Then, after opening a new guix shell without network access, I can > > confirm > > > that `cargo build` works fine with the vendored crates. > > > > > > [source.crates-io] > > > replace-with =3D "vendored-sources" > > > > > > [source.vendored-sources] > > > directory =3D "" > > > > I wanted local-registry over replace-with because IIRC replace-with > > won't fall back to downloading from crates.io if there's missing crates, > > while local-registry will check there first and then download any > > missing crates. The use-case I was looking at for that was adding a new > > dependency to a project and then not needing to re-create a shell or > > package the new crates before continuing on. > > >=20 > I see, thanks. My preferred workflow is different but I acknowledge that > use case. >=20 > The link below claims that one can update the vendor directory in a simil= ar > way by re-running `cargo vendor` after adding a dependency to Cargo.toml, > but for your use case I agree that it's nicer if `cargo build` can pull to > the registry automatically. > https://old.reddit.com/r/rust/comments/uvvmjy/how_to_include_vendored_cra= tes_into_a_project/ >=20 >=20 > > The registry as setup in the patches is actually mostly correct, minus > > the multiple versions of a crate, it just needs to be fed the crates. > > > > > Getting back to your patch set: would it make sense to emulate this > > vendor > > > workflow instead of trying to construct a registry directly? Even > > assuming > > > that all details of the registry structure are stable and documented,= the > > > layout of the vendor directory appears much simpler. And IIUC the code > > for > > > setting up vendored libraries already exists in cargo-build-system. > > > > > > I also need to figure out something with a > > > > config.toml to see if it's possible to generate one that could be > > > > included from another one, since you can't add 'local-registry =3D > > > > $GUIX_PROFILE/...' in a toml file. > > > > > > > > > > You've probably researched this more than I have, but it seems that t= his > > > use case is explicitly unsupported in the TOML language spec: > > > https://github.com/toml-lang/toml/issues/397 > > > > > > With that option off the table, I can't think of any elegant solution= s. > > > Maybe a wrapper for the cargo binary that pre-processes cargo.toml and > > then > > > calls the real cargo? > > > > Thanks, I didn't see that one. So it looks like environment variables > > and INCLUDEs are off the table. An autoconf style macro that take a > > config.toml.in and spits out a config.toml with the correct directory > > would work, but from my understanding that's not really in line with any > > bit of how cargo and the rust ecosystem works. > > > > Another option would be to symlink > > $GUIX_ENVIRONMENT/share/cargo/registry to ./local-registry and then add > > the line 'local-registry =3D 'local-registry' in a config.toml. > > --=20 Efraim Flashner =D7=A8=D7=A0=D7=A9=D7=9C=D7=A4 = =D7=9D=D7=99=D7=A8=D7=A4=D7=90 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --bHtwx6i4PlpJ2lyF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmXwcPYACgkQQarn3Mo9 g1G1Og//V/sWJbhDQFHPHxbE+QvJxfkhw0S/rzECXnbEb+SK6N2BoDhUusypaixf /4Z8eRwVEgr6OBw8gecwK/D1vfS5ZDb1v7jqarGCgLGQ3eVwx0y2cZCRha/N9r25 HBWYsbDhAG8kcjCRUlpmaEGVbgV0cpNBij7sH380wXJiR80ok2aU17mAmqbwbnLJ 2sPnYXtgTUPzJiVcLCO7ZAz0kVE1J6LYEVlv+g51E/o0qPjk8WLQGTx9lg+00TM1 453wgELDSkRjCIaIDxvo6BDpJdJqECpqXPC/rFjeIjEZuYACgSLQkfl/OMwBuJ2q 3LxmWFUN2CJ4tuWBJqD6IgcnQ6+7BLLyV73/anVvqUzGJx1rN4SPGRnv48j+A7To as4xC8IwhLzqHuwKK3ktHkk0EidX/1euROldi7GBRy8K+GcnEfzibjsYAaiQgJEj xv9y/+m22M3N2OZXLkaqMGospIjpW9RG2wFc20C3MxixU39kTMecl1NzDhjglatH /U/xuiz/gqIVua6RNHtlUjq4vlDQg+4s4tafZQcgM926ugIh2AfYqZfnIzz/KnLh vXSXKhNCJfp6lxErwj+z5CIyD4EJmQzqIBMrHHaFWoWwrxioqLK1T9EZBdC+I/1y yCkEkBhpoEXk/Wl/Fp+ly6QV7FKlDT/tgPc4zA+nspdtLxZibfc= =6yFm -----END PGP SIGNATURE----- --bHtwx6i4PlpJ2lyF--