Packaging ADDA for nix ✅

[arunoruto]

I have been an avid Nix user for quite some time, and I will be using ADDA in the future; hence, I took some time to package it up for Nix! This isn't much of an issue, but more for making my small side project public and see if someone is a nix package of ADDA.

For those who are not aware what nix is: it can be three things:

1. A functional programming language,
2. THE biggest package manager for Linux/Unix based systems, even topping Arch/AUR! source,
3. A declarative operating system (NixOS) and environment manager.

The package manager itself can be installed on any system!

The key advantage of nix is its reproducibility and huge amount of packages. It can be a bit finicky, but all in all, it is a fantastic tool!

All the dependencies of ADDA are already provided in nixpkgs, and by just switching an input argument, it will compile the normal sequential version, the MPI version, or the OpenCL version with clBLAS included!

Here is the current version of the `package.nix` file:

{
  stdenv,
  lib,
  fetchFromGitHub,
  which,
  gfortran,
  fftw,
  mpi,
  opencl-headers,
  ocl-icd,
  clfft,
  clblas,

  target ? "seq",
  # target ? "mpi",
  # target ? "ocl",
}:
let
  binaryName =
    if target == "seq" then
      "adda"
    else if target == "mpi" then
      "adda_mpi"
    else if target == "ocl" then
      "adda_ocl"
    else
      throw "Unknown target: ${target}";
  options = builtins.concatStringsSep " " (
    [ "NO_GITHASH" ] ++ (lib.optionals (target == "ocl") [ "OCL_BLAS" ])
  );
  flags = builtins.concatStringsSep " " (
    # create a list of name-value pairs for make flags
    lib.attrsets.mapAttrsToList (name: value: "${name}=${value}") {
      COMPILER = "gnu";
      OPTIONS = ''"${options}"'';
      FORT_LIB_PATH = "${gfortran.cc}/lib";
    }
    ++ [ target ] # append target to the end of the generated list, no name-value pair
  );
in
stdenv.mkDerivation (finalAttrs: {
  pname = binaryName;
  # version = "1.4.0";
  version = "1.4.0-unstable-2025-05-26";

  src = fetchFromGitHub {
    owner = "adda-team";
    repo = finalAttrs.pname;
    rev = "ac6c6be366a6f2ec6a096d8adce2ed7fffc417c2";
    hash = "sha256-sXHgAT5khKo5P9jRl7j+LDtfoXuDyttnZK6rbMWt1w4=";
    # tag = "v${finalAttrs.version}";
    # hash = "sha256-mGCWrmdut3sgWATo/Y0HCVlA67425lH8n2A1RdL7Kzg=";
  };

  nativeBuildInputs =
    [
      which
      gfortran
      fftw
    ]
    ++ (lib.optionals (target == "mpi") [
      mpi
    ])
    ++ (lib.optionals (target == "ocl") [
      opencl-headers
      ocl-icd
      clfft
      clblas
    ]);

  preBuild = ''
    makeFlagsArray+=(${flags})
    cd src/
  '';

  installPhase = ''
    runHook preInstall

    install "${target}/${binaryName}" -Dm755 -t "$out"/bin

    runHook postInstall
  '';

  meta = with lib; {
    homepage = "https://github.com/adda-team/adda";
    description = "light scattering simulator based on the discrete dipole approximation";
    license = licenses.gpl3;
    platforms = [ "x86_64-linux" ];
    maintainers = with maintainers; [ arunoruto ];
    mainProgram = binaryName;
  };
})

The latest version can always be found in my flake repository: https://github.com/arunoruto/flake/blob/main/pkgs/adda/package.nix

If someone is eager to try it out, just install nix (multi user) and you can run one of the three commands:

nix run --accept-flake-config github:arunoruto/flake#adda -- <options>
nix run --accept-flake-config github:arunoruto/flake#adda-mpi -- <options>
nix run --accept-flake-config github:arunoruto/flake#adda-ocl -- <options>

and replace <options> with the CLI params.

This setup can be also used to test builds, since nix provides to integrate unit tests and only let a build pass if the tests are passing. Since the dependencies are already in nixpkgs and will be fetched upon building, the first point provided in #316 (comment) would be solved!

If there is an interest, I could also make a PR to the nixpkgs repository and make ADDA available there!

P.S. I wanted to ask if there will be a new release in the future? If I use the v.1.4.0 tag I get some weird warnings and it errors out...

[myurkin]

Dear Mirza, thanks a lot! Unfortunately, I will not be able to test it within 1-2 weeks due to travels, but I assume that it works as you explained. So I see the following questions here:

1. Are any changes to ADDA needed to make your package more convenient or robust? Concerning the version, indeed we are very late with the new release. The version 1.4.0 leads to some errors, when compiling with modern gcc versions, but the master branch works fine and I always try to keep it stable. You can even get some name from const.h, currently it is 1.5.0-alpha3. We do plan to release 1.5 this year, but I can't commit to any specific date. I understand that referring to stable named version is, in general, better, but what are specific drawbacks of using the master branch? (maybe, there are some ways to circumvent it).

2. To have ADDA in a central nix repository would definitely be great, but let me know, if any additional changes to ADDA are required for that. This is related to the previous question.

3. Once the above is set, how should we advertise this package to ADDA users? The obvious place seems to be to add a Section about packages into CompilingADDA. Other packages will probably also appear. Or maybe somewhere else - what do you think?

4. Finally, what is the nix attitude towards old packages? Specifically, there is an issue with clfft at Homebrew - see https://github.com/adda-team/adda/wiki/InstallingclFFT#macos . Is nix susceptible to it (now or in the future)? Otherwise, it seems that nix solution for ADDA on MacOS is much easier than that through Homebrew. Is that correct?

[arunoruto]

Dear Mirza, thanks a lot! Unfortunately, I will not be able to test it within 1-2 weeks due to travels, but I assume that it works as you explained. So I see the following questions here:

There is no need to rush! I have tested it on my local machine(s) and used the examples scripts, albeit with some modifications!
And I just looked up and saw you are also gonna attend ELS this year, maybe we can chat a bit in the following days ;)

1. Are any changes to ADDA needed to make your package more convenient or robust? Concerning the version, indeed we are very late with the new release. The version 1.4.0 leads to some errors, when compiling with modern gcc versions, but the master branch works fine and I always try to keep it stable. You can even get some name from `const.h`, currently it is 1.5.0-alpha3. We do plan to release 1.5 this year, but I can't commit to any specific date. I understand that referring to stable named version is, in general, better, but what are specific drawbacks of using the master branch? (maybe, there are some ways to circumvent it).

I am asking regarding the new release, since Nix has an auto update mechanism, it will periodically scan a repo for new tags and auto update the tag reference and hash associated with the tag commit! While not mandatory to have the auto update on, it is nice to have, so the newest release is always built in the future :) Currently, I am using an unstable versioning scheme, which references a commit hash instead of a release tag.

2. To have ADDA in a central nix repository would definitely be great, but let me know, if any additional changes to ADDA are required for that. This is related to the previous question.

AFAIK, no changes are needed! This was one of the pleasant projects to package up for nix :D Sometimes it can be really cumbersome, for example ISIS3 👀 With a potential 1.5.x release, I would make a PR to the nixpkgs repository and add myself as a maintainer! In the future, the command to run it would be much easier, like nix shell nixpkgs#adda would spawn a new shell with the adda binary available in PATH.

3. Once the above is set, how should we advertise this package to ADDA users? The obvious place seems to be to add a Section about packages into [CompilingADDA](https://github.com/adda-team/adda/wiki/CompilingADDA). Other packages will probably also appear. Or maybe somewhere else - what do you think?

The wiki would be a good starting point! I am not sure how widespread Nix is in the scientific community, and while I adore it, I am also against forcing it upon others. I was also thinking of giving a small workshop at the conference on the reproducibility of software projects, but due to the (typical) lack of time, I had to abandon the idea.

4. Finally, what is the nix attitude towards old packages? Specifically, there is an issue with clfft at Homebrew - see https://github.com/adda-team/adda/wiki/InstallingclFFT#macos . Is nix susceptible to it (now or in the future)? Otherwise, it seems that nix solution for ADDA on MacOS is much easier than [that through Homebrew](https://github.com/adda-team/adda/wiki/CompilingADDA#macos). Is that correct?

This is a tough one! Nixpkgs has a few branches, but the two most important ones are nixos-xy.ab and nixos-unstable. xy.ab is similar to Ubuntu's release cycle, xy is the year, and ab is the month (typically 05 (May release) or 11 (November release)). They pin the binaries to a specific version, then do a lot of testing to ensure that everything compiles, and fix the branch. While unstable sounds scary, I am unaware that it is unstable; things have not been tested like they have been on the stable branch.
So, what does this have to do with old packages? Nixpkgs keeps references to the respective latest version of a package. If a package is deprecated and isn't used by any other project, it can possibly be removed. But that isn't usually such a problem. And even if it happens, we can copy the "build script" and add it to ADDA's packaging :)
I am not sure if all the packages would compile for macOS. Maybe some things need to be changed, but the sequential version should work out of the box, since it only depends on GCC, which is provided by the standard environment stdenv. If you have a Mac system, we can test it out. But in the long run, it is much easier to maintain it for Darwin (MacOS) systems this way! Nix provides flags like isDarwin to identify if the target system has MacOS and can then use other packages to build the project!