Hi, Reading this thread: https://social.sciences.re/@alxsim@ecoevo.social/114032640094854151
Let resume this discussion here. :-) Well, I know antioxidant and also that Nicolas did some piece of works but lost it! )-: (see #64904) And Murilo sent ideas [1] some time ago. And cargo2guix [2] does good job too! In order to ease, I just copy below message from [1]. Hey what’s the status? What’s the plan for improving the whole Rust story with Guix? 1: Idea for packaging rust apps "Murilo" <mur...@disroot.org> Tue, 21 May 2024 23:04:44 -0300 id:D1FSEA12TP5X.3DXKC14DE114M@yumiko https://lists.gnu.org/archive/html/guix-devel/2024-05 https://yhetil.org/guix/D1FSEA12TP5X.3DXKC14DE114M@yumiko 2: https://git.sr.ht/~look/cargo2guix On Tue, 21 May 2024 at 23:04, "Murilo" <mur...@disroot.org> wrote: > It is a very simple tool, it essentially parses the Cargo.lock file and > extracts all the relevant information for constructing the rust package > definitions of all the cargo-inputs and the package itself, and outputs > to stdio a guile module containing all the needed cargo-input chain as > guix packages, with all the cargo-inputs self-contained and versions all > sorted out for a working final package build. > > This way a packager only needs to focus on the actual package they are > trying to build, instead of worrying about its cargo-inputs. How does it compare with antioxidant? And your (Nicolas) ideas? > I would like to propose some discussion around a better way of organizing > the rust packages and its cargo-inputs in (gnu packages) for building > rust apps that only need sources as cargo-inputs: > > 1) Create a new directory at gnu/packages/rust/ in which a contributor > can commit self-contained rust apps scm modules. > 2.1) Add a new module at gnu/packages/rust/my-rust-app-1.scm > 2.2) Add a new module at gnu/packages/rust/my-rust-app-2.scm > 3) All package definitions inside gnu/packages/rust/*.scm which are > source-only (#:skip-build? #t) should not be exported. > 4.1) gnu/packages/crates-*.scm will not cease to exist, existing rust > apps packages that have a Cargo.lock could gradually be migrated > to the new organization > 4.2) libs which need to be built can still live in > gnu/packages/crates-*.scm > 5) A (define-public my-rust-app-1 (@@ (gnu packages rust my-rust-app-1) > my-rust-app-1)) or equivalent could be done in a (gnu packages > category) module to export the rust app in the desired category. > 6) Unlike nix (which also parses the Cargo.lock in the build system), > we don't lose the ability to make snippets for sources this way. > 7) For updating/maintaining a rust package defined this way, one would > be able to simply re-run the guix tool, and replace the > gnu/packages/rust/my-rust-app.scm file, only copying over the final > relevant package definition for the rust app with its tweaks for > building, and passing over the new cargo-inputs generated by the guix > tool. Well, I do not have any strong opinion. Rust team, WDYT? > I believe that by only changing the way things are organized and having > a guix tool that generates self-contained package definitions from > Cargo.lock, it would be possible to greatly improve the time required > for contributing new rust apps packages and maintaining them on Guix. Murilo, it was your initial thoughts. What’s your current ideas? Based on some months of experience and maybe some deeper dive into Rust build system by Guix. Cheers, simon
