From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:58273) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZgLt-00043m-SL for guix-patches@gnu.org; Sat, 08 Jun 2019 14:46:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hZgLr-0007Wb-Oi for guix-patches@gnu.org; Sat, 08 Jun 2019 14:46:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:40165) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hZgLq-0007Ub-HJ for guix-patches@gnu.org; Sat, 08 Jun 2019 14:46:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hZgLq-0004Yf-Ei for guix-patches@gnu.org; Sat, 08 Jun 2019 14:46:02 -0400 Subject: [bug#35318] [PATCH] Update cargo-build-system to expand package inputs Resent-Message-ID: From: Chris Marusich References: <87ftpsnhal.fsf@gnu.org> <2C03880B-F90E-4949-9637-DC918B6D40A0@gmail.com> <074E4899-C4FF-4A76-8E97-093378D2F8D5@gmail.com> <87pnojvqdu.fsf@gnu.org> <6A0A0108-A722-4D73-85B7-E61AB8230026@gmail.com> Date: Sat, 08 Jun 2019 11:44:55 -0700 In-Reply-To: <6A0A0108-A722-4D73-85B7-E61AB8230026@gmail.com> (Ivan Petkov's message of "Sun, 19 May 2019 18:00:01 -0700") Message-ID: <87ftoj9as8.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ivan Petkov Cc: 35318@debbugs.gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Ivan, Sorry for taking so long to review this. In short, I think these changes are good, and if nobody has more feedback in the next few days, I will merge it and we can see how it works in practice! At a high level, I think these changes have the following pros and cons: Pros: - We can now build Rust crates. Fantastic! - The "dependencies" and "dev-dependencies" terminology is the same as Cargo uses, so it will be familiar to Rust programmers. - We avoid O(N^2) build time, where N is the number of dependencies. - We can use the importer to quickly import new crates and iterate. Cons: - Because the "dependencies" and "dev-dependencies" are specified as package arguments instead of any kind of "input", they won't show up in some of the graphs produced by "guix package". However, in theory "guix graph" could be taught to display nodes for crate "dependencies" and "dev-dependencies", too. =20=20=20=20=20=20 - Everyone who defines a Guix package for a crate must make sure the origin's file name ends in ".cargo", since the cargo-build-system now assumes that any input ending in ".cargo" is a crate that should be extracted into the build's crate-dir. This is a little brittle, and I wish we had a better way to check this, but I can't think of a better way at the moment. Since you've updated the importer to always add this, it probably won't be much of an issue in practice, since that's the default way new crates will be added to Guix. Going forward, maybe we can avoid this by just checking the inputs to see which ones are gzipped tarballs containing Cargo.toml files. Limitations imposed by Rust/Cargo itself: - I'm not a Rust or Cargo expert, but my current understanding is that it isn't feasible to save the artifacts produced when building a crate for re-use when building another crate. In the world of C, it is common to produce a library, and then link against that library when building other software later. In Guix, when building a C library, we install the built artifacts (e.g., .so files) into the output, so that those artifacts can be used as the input for another package's build. It seems that, by Cargo's design, it isn't currently feasible to do the same sort of thing with Cargo: that is, it isn't feasible to build artifacts, install them somewhere for later use, and then later re-use them in another Cargo build. I'd be glad to learn that I'm mistaken, but currently that is my understanding. - Related to this, I doubt that a Rust programmer will be able to invoke a command like "guix environment my-crate" (even if we teach it to understand crate "dependencies" and "dev-dependencies") to make all the dependencies required to build my-crate available. If a Rust programmer wants to hack on my-crate, they'll probably still just use "cargo" to do it without using Guix at all. Is there any way to avoid this and make it possible to get the dependencies used by Guix in the build, so that a Rust programmer can hack around using precisely those dependencies? If this were C or Python, you could do that using "guix environment," but I'm not sure how this could work with Rust crates. Thanks again for working on this! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlz8AicACgkQ3UCaFdgi Rp0zWg/+Kp3+TU4z4vQUW6gczOYeguf2hNuDl1n6F77mhOg0SbjowkylP8gOldZo 9oBE2ErU7nYuZuWgeJSDI1ux/MLLpgOnz7nle4oE9lZNxJnrjhsoqOh+lXoFJ3b8 n9OEVaBt0RfTDoixo1oCByJSdharclt+PwReazvqQRByhW8F9S4Hz1tFCnpoq4O/ znkQ5wFNgYvMTOFvHG9OVKUhbXbZStO8ugHdUYw2Wo9BTEf5y3WFKx8yZSSLCQVs pUJlLt8hx+pYzgsrRF/KN8N3Ui+ZOwPcV5/nXYp083IJ47EA5iyal7P4WcPKDJtq wHQRpBkpIcLKM1L52dH8n/0fo3x+zbxLZJXwpvMwUhJrEgSACP7Mk03FZOMVt6Z9 dEBsqukK6DfAWLdxOEX99ahiM9tk17SMQ5TmaDdG/MUdq5bnXi7zka7TbaF9M86+ Ztj9RlzdpPJ4G5CnutHhOfAsO/EHqNtd1Jl8vTMzxYo8LgudGVbvMcPq0eiAMAY4 ye8gvnBTFNO+/LTkeXFdNXZYenbmiwFpPHlA0DmnCsS/Tizv51bDLdPfcodke0AV 4kiRqk8qbGhmCKb/XtMqulqhZ8b2GkAUt3UOPlAhuS/ClY9lywX1QNB/eCb2zMRI u3nCkL43STMRCJok/yocXrhLrzaEULZ4AW07F3sJ4vg0JG3PxTE= =xlDy -----END PGP SIGNATURE----- --=-=-=--