On Thu, 27 Feb 2025 02:45:33 +0800, Murilo wrote: > > On Wed Feb 26, 2025 at 12:30 PM -03, Efraim Flashner wrote: > > I was looking closely at cargo2guix earlier this week, and I hacked up > > that if a [[package]] had a source but no checksum it was a git > > reference, and if it had no source and no checksum then it must be > > inside the workspace. > > Yes, this is true. I've known this for a while but never had the motivation > to implement some logic for it in cargo2guix. I've been removing the workspace > cargo-inputs by hand until now - thanks for the patch by the way, I'll look at > it later :) > > > Looking at guix/build/cargo-build-system, the "easiest" option would be > > to take the git-checkout and then turn it into a .tar.gz. Otherwise > > crate-src? and 'configure would need to be adjusted to handle git > > checkouts. > > I think so too, while its easier it feels a bit hacky, but it should do the > job > for now. We could always do a proper support for git checkouts later. > > --- > (A bit of a parenthesis) > Perhaps its also a good time to add "--offline" to all cargo invokes to > effectively prevent it from executing online operations. > --- > > > Would it be easier to have 1 package per module, as in just the cargo > > inputs for zoxide in gnu/packages/rust-crates/zoxide.scm, and then you > > wouldn't need to worry about removing variables that aren't used by > > zoxide anymore but are used by another package? > > I agree with Efraim here. My initial thoughts were to have one package per > module not only because its easier to do, but also because it avoids any > merge/rebase conflicts with other packages/patches.
Nice point! We can split change to one package into two commits: 1. Automated work (crates addition and deletion) 2. Manual work (crates modification, package definiton) When submitting a patch series, 1 is for CI/QA purpose. Committers are responsible for recreating the change following documented workflow and only apply 2.
