Conversation

Notices

1. Embed this notice
   ⠴PicNoir⠦ (picnoir@social.alternativebit.fr)'s status on Saturday, 23-Nov-2024 22:22:33 JST ⠴PicNoir⠦

   • Ludovic Courtès
   @civodul all of the above plus the adoption of FOD-based dependencies fetchers for the Rust and Go toolchains. (wrote this in the survey a few days ago, I sound like a broken record!)
   
   It's definitely a tradeoff, patching a Rust or Go library for the whole packageset is definitly not an option for Nixpkgs. At least not a realistic one at the moment. But that's a tradeoff I personally think makes sense. The very little experience of packaging a not so complicated Rust package on Guix has been horrendeous. The importer is brittle, it generates a lot of code that you have to manually massage into the tree. All this is unecessary busywork in my opinion.
   
   This plus my very limited experience with email-based workflows has been the real show-stopper for me during my latest attempt to use Guix more.
   
   --------------------------------
   
   I also feel like we need a Guix counterpart of nixpkgs-review for reviewers. This is a really important tool for me, and last time I checked (granted a few months ago), there were no credible option in the Guix land.
   
   https://github.com/Mic92/nixpkgs-review
   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Saturday, 23-Nov-2024 22:22:31 JST Ludovic Courtès

     in reply to

     @picnoir Could you explain a bit the FOD-based dependencies fetchers (or send a link)? (I always read “FOD” is “FUD”; for those like me, we’re talking about fixed-output derivations. :-))

     ‘nixpkgs-review’ looks pretty cool indeed; the recently-added ‘mumi am’ helps, but it only does a tiny part of the job.

     How does ‘nixpkgs-review’ figure out which packages (if any) need to be rebuilt to validate a PR?

   • Embed this notice
     ⠴PicNoir⠦ (picnoir@social.alternativebit.fr)'s status on Tuesday, 26-Nov-2024 00:27:14 JST ⠴PicNoir⠦

     in reply to

     • Ludovic Courtès
     @civodul As for nixpkgs-review, the heavy lifting is currently done by ofborg, the soon to be discontinued PR CI. (ie. the component evaluating and building the PRs, but not populating the cache/building the channels).
     
     For each PR, ofborg evaluates Nixpkgs and checks the changed paths. It then creates a gist listing the updated packages (for instance https://gist.github.com/GrahamcOfBorg/b65fc0e8791f16ae1a0be898a9b2779d). Nixpkgs-review retrieves this file for the PR we want to review (https://github.com/Mic92/nixpkgs-review/blob/907925df227584ae4c0eb38db51fd23fe495d276/nixpkgs_review/github.py#L89) and locally evaluates/builds the changed packages.
     
     There's also an option to inhibit this behaviour and evaluate everything locally, without using ofborg https://github.com/Mic92/nixpkgs-review/blob/907925df227584ae4c0eb38db51fd23fe495d276/nixpkgs_review/cli/__init__.py#L41.
     
     But in practice, it requires a quite beefy machine to be usable. I personally don't do that on my computers.
   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Tuesday, 26-Nov-2024 00:30:32 JST Ludovic Courtès

     in reply to

     @picnoir Thanks for explaining!

     The changed path computation is similar to what the Guix Data Service does, and it’s indeed expensive (and the main bottleneck for qa.guix right now).

   • Embed this notice
     Ludovic Courtès (civodul@toot.aquilenet.fr)'s status on Tuesday, 26-Nov-2024 06:05:57 JST Ludovic Courtès

     in reply to

     • Octorine
     • PuercoPop

     @picnoir It’s a FOD whose output hash cannot be known in advance too, so I suppose one just builds it, looks at the hash mismatch error, and feeds the “expected” hash back in the package definition?

     @PuercoPop @octorine

   • Embed this notice
     ⠴PicNoir⠦ (picnoir@social.alternativebit.fr)'s status on Tuesday, 26-Nov-2024 06:05:59 JST ⠴PicNoir⠦

     in reply to

     • Ludovic Courtès
     • Octorine
     • PuercoPop
     @octorine @PuercoPop @civodul That's correct. It looks like this in practice: https://github.com/NinjaTrappeur/nixpkgs/blob/23586a2787da6d0b91c2abd8f3c6cc7bfa70d950/pkgs/tools/admin/coldsnap/default.nix#L18
     
     But again, it's a tradeoff. You're giving cargo full control of part of the build graph and become partially blind to the dependencies.
   • Embed this notice
     PuercoPop (puercopop@mastodon.social)'s status on Tuesday, 26-Nov-2024 06:06:00 JST PuercoPop

     in reply to

     • Ludovic Courtès

     @civodul @picnoir FOD stands for fixed output derivations. IIUC what PicNoir is suggesting that guix should use the lockfile of the Go/Rust package to define an intermediate package that contains all the dependencies for a package. This leads to less conflicts trying to find common versions that work for multiple crates at the expense of more storage requirements and longer build times

   • Embed this notice
     Octorine (octorine@fosstodon.org)'s status on Tuesday, 26-Nov-2024 06:06:00 JST Octorine

     in reply to

     • Ludovic Courtès
     • PuercoPop

     @PuercoPop @civodul @picnoir If I'm understanding this correctly, the dependencies would only exist in the FOD and wouldn't need to be explicitly packaged and included in nixpkgs, right?