fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

Dear #Nix contributors,

What do you think is key to making Nixpkgs the most up-to-date distro?

@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
GitHubGitHub - Mic92/nixpkgs-review: Review pull-requests on https://github.com/NixOS/nixpkgsReview pull-requests on https://github.com/NixOS/nixpkgs - Mic92/nixpkgs-review

@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?

@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

Octorine

@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?

@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

@civodul @PuercoPop @octorine Yeah, it's TOFU-based.

As I was (confusingly!) saying in https://social.alternativebit.fr/notice/AoP4aOPvbQxXy0f0T2, there are two ways to specify this output hash at the moment. Let me try to rephrase that and try being less confusing this time :D

You can either explicitly give the output hash (TOFU-style, like in the link I shared in the last toot) or you can point to the package lockfile. That lockfile contains all the dependencies hashes, no need to TOFU.

For instance: https://github.com/NixOS/nixpkgs/blob/207c5d0c0d93ab7d317bf94a481adf739ad60e15/pkgs/applications/video/youtube-tui/default.nix#L28

You don't have access to the full build graph in both cases, you're delegating the package build to the underlying build system (here cargo).

These two styles come with different tradeoffs:

- the TOFU hash is conceptually more brittle.
- the lockfile approach implies having the lockfile living in the Nixpkgs repo (you need it at eval time), so tend to litter the already massive git repo and costs a bit more eval-wise: you need to parse the full lockfile json.
social.alternativebit.fr⠴PicNoir⠦ (@picnoir@social.alternativebit.fr)@PuercoPop @civodul Yeah, that's pretty much it. Let's take the rust example. You have a `buildRustPackage` (https://github.com/NinjaTrappeur/nixpkgs/blob/23586a2787da6d0b91c2abd8f3c6cc7bfa70d950/...

@picnoir @octorine @PuercoPop @civodul TIL that the lockfile has to live in nixpkgs. I thought it's computed on-demand from the source. (Guix actually can't do this because the list of inputs is used quite often, even though it's also computed-on-demand)

@Parnikkapore Yeah, it's one of the current limitation of Nixpkgs: you can't do IFDs (https://nix.dev/manual/nix/2.23/language/import-from-derivation) in it.

If you were to download the cargo lockfile, you'd be then reading the output of this source fetch derivation and parsing its content into a Nix expression through fromJSON, you'd be semi-accidentally doing an IFD.
nix.devImport From Derivation - Nix Reference Manual

@picnoir @octorine @civodul One thing to add is that it is trade-off that might make sense in the context of distributing software to end users, but not for development. The amount of rust desktop _applications_ is probably around ~100.

@picnoir @octorine @civodul For development the nix ecosystem has other alternatives like github.com/ipetkov/crane or github.com/oxalica/nocargo. I'm mostly familiar with crane, that although uses the cargo.lock as the source of truth for dependencies it stores each crate separately in the store so that changing one dependency doesn't require a full recompilation of dependencies.

GitHubGitHub - ipetkov/crane: A Nix library for building cargo projects. Never build twice thanks to incremental artifact caching.A Nix library for building cargo projects. Never build twice thanks to incremental artifact caching. - ipetkov/crane