19. Upgrading

Here are some workflow suggestions when you’re trying to upgrade packages (or GHC) in wire-server.

  • Use and install nix-output-monitor when building nix derivations locally. It shows you the dependency tree building as well as the progress. This can give you a sense for much progress you’ve made.

  • The .envrc environment probably won’t load anymore. To fix this adjust the for packages that get passed to shellFor in wire-server.nix. In the beginning you might want to start out with an empty list as an argument.

  • You can explore our nix derivations via nix repl and then :l ./nix to load the attrset in ./nix/default.nix. For example to see which version of aeson will be used you can evaluate wireServer.haskellPackages.aeson.version. TAB-autocompletion also tells you if multiple versions of a package are included in the nixpkgs pin, e.g. aeson_1_5_6_0, aeson_2_1_1_0, which can be used in manual-overrides.nix to overwrite the default, e.g. aeson.

  • Your goal is to make all packages compile again with nix. Start small by trying to build single packages, e.g. wire-api or any external dependencies.

nix-build ./nix -A wireServer.haskellPackagesUnoptimizedNoDocs.wire-api

  • When a dependency doesn’t build anymore because of unmet version constraints see if you can use a never version (haskell-pins.nix, or manual-overrides.nix if multiple versions of the package are included in the nixpkgs pin). Also check out the git repo or issue tracker of the dependency to find forks that work. You can also try removing versions constraints of packages: see doJailbreak in manual-overrides.nix.

  • If test-suites of a dependency don’t compile, or cannot be run because they require IO interaction you can disable them: see dontCheck in manual-overrides.nix

  • To force a rebuild of the nix shell delete the .env directory and run direnv reload

  • If you need to fix code in a dependency consider forking it and creating a PR to the upstream after successful integration. Clone the repo and then symlink it inside libs/ then run generate-local-nix-packages.sh to temporarily include its dependencies in the development shell. Make sure to include the package in shellFor. If you’ve got a working shell you can check the output of ghc-pkg dump to see the list of nix-provided ghc packages used by cabal.

  • Consider using ghcid --command "cabal repl <package>" when fixing packages

  • Delete the dist-newstyle directory everytime you upgrade the nix environment, without any exception. That is because cabal does not pick up changes to the ghc-pkg set (defined the development shell). Cabal will complain about missing dependencies in these cases.

  • When trying to build any packages with cabal (e.g. for fixing code in a depencency or fixing local packages), make sure you’ve got the right package set in the shellFor argument and the right transitive dependencies in cabal.project. It takes a couple of tries to get both: a nix provided environment that works, and cabal not complaining about missing dependencies when building inside the environment.

  • It might happen that a package’s test suite dependencies are not available in the nix environment. When you try to build with cabal it might try to build these external dependencies (which you want to avoid). What might work in these cases is to temporarily update the default.nix file (generated by generate-local-nix-packages.sh) to add the test suits dependencies to the library section.

  • If cabal is complaining about a missing libsodium, add sodium-crypt-sign to the shellFor environment.