Jason Conroy <jcon...@tscripta.net> writes: > Hilton Chain <hako@ultrarare.space> writes: > >> Hilton Chain <hako@ultrarare.space> writes: >> >>> On Tue, 18 Mar 2025 15:30:30 +0800, >>> Hilton Chain wrote: >>>> >>>> Patch series without packages sent to #77093! >>> >>> Finally added the lockfile importer to rust-team branch! >>> #77093 is left for >>> documentation and will be a merge blocker. >> >> Blog post sumbitted as: >> https://codeberg.org/guix/artwork/pulls/1 > > Hilton, thank you for the nice writeup. I've been following the > discussion at a distance, so this is a somewhat naive question > about the developer workflow under your proposal. > > When using Guix with other languages, I find "guix shell" > extremely convenient for setting up a project's dependencies. The > produced environment gives me confidence that: > > a) the lib dependencies have versions that the Guix community has > already vetted and used successfully; > > b) all transitive dependencies of those libs are available, and > also have known-good versions; > > c) any work required to patch the libraries for Guix builds has > already been done, so there are no surprises later on.
Unfortunately, all existing approaches don't involve supporting Rust libraries in `guix shell`. > With Rust, it seems as though the status quo is different: people > mainly rely on cargo for their dev environment, and then add Guix > definitions later, for packaging the final application. Am I > describing that situation fairly, and do your proposed changes > influence the model in one direction or another? The decision to > move away from "real" packages for library crates and sources > seems significant here, but I don't know exactly what it means. We're not using these "real" packages. When adding a Rust library into #:cargo-inputs, its source will be used, not the build output. The build output is usually a repacked source though, not something we can make good use of either.
