Conversation

Notices

1. 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⠦

   @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 Saturday, 23-Nov-2024 22:22:33 JST ⠴PicNoir⠦
     @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