Is importing a derivation from another repository bad practice?

Development
1

I am working on packaging rmapi in this pull request. My approach was:

  1. Add all the nix relevant files (default.nix, deps.nix, derivation.nix, shell.nix) to the rmapi repository (Pull Request)
  2. Add a derivation to nixpkgs which fetches and uses derivation.nix from the rmapi repository.

My thinking was that by storing derivation.nix, deps.nix and shell.nix in the rmapi repository I can:

  • add a github action which automatically updates deps.nix
  • add support for a nix-shell powered development environment

My problem right now is that my pull request to nixpkgs does not pass ci checks. I do think this happens because pkgs/applications/office/rmapi/default.nix uses fetchFromGithub to load the derivation.nix from the rmapi repository. Which won’t work during ofborg evaluation because of security / sandboxing.

If that’s the case: Is the my chosen approach wrong?

2

I think such an approach has the downside that in order to update a package in nixpkgs one is always blocked on waiting until the upstream accepts an update to the upstream Nix files. Also, it makes updates more involved, since you have to update a derivation in two places (with two PRs).

3

You don’t have to wait for the upstream pr to be merge. In the example, the upstream PR is not merged, yet. The package in nixpkgs just points at my fork.

4

Sadly, IFD is not supported in Hydra, since all evaluations runs on main Hydra machine (instead of slaves), it would slow down everything.

I’ve written about how IFD does help with development best practices as you’ve wanted to deduplicate expressions between the repositories to save developer time.

Until CI in nixpkgs allows IFD you’ll need to find a way to sync Nix expressions between your repository and nixpkgs.

2 Likes
5

Thank you for the explanation @domenkozar. This makes perfect sense. I now copied derivation.nix and deps.nix into nixpkgs .

I have spent quite some time investigating this because the error i got from ofborg is very cryptic. Will investigate now if I can improve this…

6

My assumption was that you’d want nixpkgs to point at the upstream URL (once the PR was merged). Not doing so means that if someone else wants to update the derivation at some point in the future, they will have to fork the repository as well (or submit a PR for your fork, which means 2 PRs again). Also, it puts an extra burden on reviewers if a derivation does not point to a trusted upstream. You’d have to diff against the upstream code and ensure that it is not an older version with known vulnerabilities.

7

Yes, this was my plan. And it would have worked because the upstream ci/cd system ensures that the derivation builds and deps.nix is in sync with their go.mod.

Only if nixpkgs changed buildGoModule in a way that the committed derivation.nix is no longer compatible with the version provided by nixpkgs the derivation.nix in upstream would needs to change first before the package can be updated. Which is imho. quite a rare edge-case. Also in that case, the two Pull requests still don’t depend on each other because nixpkgs could temporarily point to a fork.

Honestly I would prefer keeping deps.nix next to go.mod. Now I have to manually maintain a copy of that file in nixpkgs.