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?
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.)
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.
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.