Deduplicating a package definition between nixpkgs and a Flake

Development
1

I’m developing some software (ldgallery) and I’m currently maintaining
the matching package in nixpkgs. I’ve recently added a Nix Flake to the
project’s repository.

The two package definitions are quite different:

  • The one in the Flake can rely on Import From Derivation to
    directly use the dependencies lock files in the project’s repository,
    whereas
  • the one in nixpkgs uses a copy of .nix files manually derived with
    *2nix tools and committed to the package collection.

I now have to maintain two distinct packages for the same software.

Is there a way to instead re-export the definition from the Flake in
nixpkgs?

Or is maintaining two copies the proper way? If so, how could one
minimise the differences between the package definitions so that they
could simply be copy-pasted to update the package in nixpkgs?

Alternatively, should this somewhat niche package simply be dropped from
nixpkgs and instead be added to the Flake index of search.nixos.org?

1 Like
2

No! Please don’t! The following downloaded 4GiB of darwin specific trash into my store before it failed…

$ nix flake show github:ldgallery/ldgallery --option allow-import-from-derivation true
github:ldgallery/ldgallery/8349be992b46b77dee921f484cfbff8b758ff756
├───apps
│   ├───aarch64-darwin
│   │   ├───default: app
│   │   └───ldgallery: app
│   ├───aarch64-linux
│   │   ├───default: app
│   │   └───ldgallery: app
│   ├───i686-linux
│   │   ├───default: app
│   │   └───ldgallery: app
│   ├───x86_64-darwin
│   │   ├───default: app
│   │   └───ldgallery: app
│   └───x86_64-linux
│       ├───default: app
│       └───ldgallery: app
└───packages
    ├───aarch64-darwin
error: a 'aarch64-darwin' with features {} is required to build '/nix/store/0hm6hz66vzxdn6155s7xzjlk65acdn6n-cabal2nix-.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}
(use '--show-trace' to show detailed location information)
1 Like
3

I understand your concern @NobbZ, but what should be done here? Now it seems like we have two issues: ifd/cross platform is an anti pattern and @pacien needs to maintain two flakes.

Furthermore, telling developers who want to maintain a flake, that they need to check in a language level lock file and a derived nix file, is a bit of a nonstarter, imo. (The fact that ifd can reuse language lock files is a big selling point for me over other hermetic builders, e.g. bazel.)

1 Like
4

There are ways to not use IFD and not commit a “translated” lockfile.

naersk works well for me in that regard.

As you also might have seen, actually the nix flake show would have failed much earlier for me, as I have allow-import-from-derivation = false in the nix.conf, and I am really waiting for the day when that becomes the default.

Though nix flake show: don't evaluate derivations for foreign systems by default by max-privatevoid · Pull Request #6988 · NixOS/nix · GitHub could make both of us happy. I could at least consciously inspect such a flake, though would still not consume from it…

2 Likes
5

naersk is only for rust, so other languages may just require ifd, until somebody writes a better deriver?

should we be documenting things like mkYarnPackage as needing caution due to ifd usage?

finally, there has been precious little discussion of @pacien’s root issue, surrounding the need to maintain two copies of this derivation. I am curious on best practice here too.

1 Like