On Thu Mar 6, 2025 at 2:24 PM -03, Efraim Flashner wrote:
> On Wed, Mar 05, 2025 at 09:20:50PM +0800, Hilton Chain wrote:
>> 1. Unpack package source then update lockfile:
>> --8<---------------cut here---------------start------------->8---
>> cargo generate-lockfile
>> --8<---------------cut here---------------end--------------->8---
>>
>> 2. For adding new packages check output of ‘cargo audit’ and ‘cargo license’.
>
> These two were easy. I realized later that we could forgo running
> 'cargo generate-lockfile' if we wanted to use the Cargo.lock that
> already exists (if it does), but we probably want to make sure we have
> more up-to-date dependencies as much as possible. I could see, as part
> of a rust-team branch, going through and updating the lockfile every now
> and then even if there is no update to the actual package, as the
> dependencies get updated upstream.
I think always having the most up-to-date dependencies is a good thing as well.
Just something to keep in mind when doing this is that when we ship the same
lock as the upstream release tag, we are making sure the final program will
behave as closest as possible to the release version shipped upstream.
This is a good thing for upstream because it can receive bug reports from guix
users without much worry about the dependency chain being different and we are
more likely to have the same issues as upstream has.
So while I think the chances are low, there's always a chance of something
breaking at runtime if we start bumping the locks. Even if the semver is
compatible you never know how the final program might behave.
Again, not against it, just something to keep in mind.
>> 3. Update module
>> --8<---------------cut here---------------start------------->8---
>> guix import --insert gnu/packages/rust-crates.scm crate --lockfile=<...>
>> <...>
>> etc/teams/rust/cleanup-crates.sh
>> --8<---------------cut here---------------end--------------->8---
>
> I got tripped up with this a bit. --lockfile=path/to/lockfile <pkg>
Also, not sure if its a shell thing, but I spent a couple minutes until I
realised that passing '~' to --lockfile didn't work (it triggered the normal
crate importer, without lockfile, instead) like so:
---
Does not work as expected:
$ guix shell -D guix -- ./pre-inst-env guix import \
--insert gnu/packages/rust-crates.scm crate \
--lockfile=~/path/to/Cargo.lock <package>
Works as expected:
$ guix shell -D guix -- ./pre-inst-env guix import \
--insert gnu/packages/rust-crates.scm crate \
--lockfile=/path/to/Cargo.lock <package>
---
> I had 4 dependencies which needed git-fetch, and I packaged them in
> rust-crates.scm also. I tried changing the names to
> rust-xx-for-uv.tar.gz, but that didn't trick cargo into unpacking them.
> In the end I had to add them as inputs and copy them over manually. One
> of them, version-ranges, was inside a directory of another one, which
> was annoying to figure out, and I think would've needed manual
> intervention even if git sources were unpacked automagically.
A bit of a hack I do is to use the forge archive links for these, for example:
---
(origin
(method url-fetch)
(uri
"https://github.com/pythonesque/shaderc-rs/archive/f2605a02062834019bedff911aee2fd2998c49f9.tar.gz";)
(file-name (string-append name "-" version ".tar.gz"))
(sha256 (base32 "14na50a585lb0pkdz3kraw2sgk8qjd78972aimcwdlkl9kyvvd0z")))
---
Then it already comes in '.tar.gz' and gets handled by cargo-build-system.
Not the best, but it gets the job done and I think its easier than modifying the
phases to add the extra sources.
On Wed Mar 5, 2025 at 10:20 AM -03, Hilton Chain wrote:
> My current workflow uses these packages:
> --8<---------------cut here---------------start------------->8---
> guix shell rust rust:cargo cargo-audit cargo-license
> --8<---------------cut here---------------end--------------->8---
>
> 1. Unpack package source then update lockfile:
> --8<---------------cut here---------------start------------->8---
> cargo generate-lockfile
> --8<---------------cut here---------------end--------------->8---
>
> 2. For adding new packages check output of ‘cargo audit’ and ‘cargo license’.
>
> 3. Update module
> --8<---------------cut here---------------start------------->8---
> guix import --insert gnu/packages/rust-crates.scm crate --lockfile=<...> <...>
> etc/teams/rust/cleanup-crates.sh
> --8<---------------cut here---------------end--------------->8---
>
> 4. Check module diff, content of sources marked as TODO and output of
> 'check-for-pregenerated-files phase.
I tried it on a couple packages, the importer seems to work really well, so far
so good.
> I added etc/teams/rust/rust-crates.tmpl in case multiple modules are wanted.
> But I still hope you to try the one-module approach first :)
I'm still a bit concerned about having too many git conflicts to solve when
multiple patches from different people start coming at the same time, but you're
right, we will never know without trying it first.
One option if we ever decide to switch to multiple modules in the future could
be to have a single-module for everything that has snippets and unbundling to
do, and have the importer warn about already existent packages/sources to use
so it avoids the duplicate work (and any possible snippetting/unbundling to do,
e.g. for a different version of an existing unbundled source), while still using
the multiple modules approach to avoid conflicts.
I'll be testing some more complex packages with the current 'cargo' branch in
the following days, but for now, in easier rust apps, the workflow has been
pretty pleasing, and no problems yet :)
