Upgrading replaced ghc-with-packages with ghc

[shanemikel]

I was a little surprised tonight to see that doing a nix-channel --update and nix-env --upgrade replaced my ghc 8.0.1 "with-packages" environment with the vanilla ghc 8.0.2.

Not a big problem, and I don't have time to investigate ATM, but it doesn't seem like the "right" behavior.

[domenkozar]

What channel are you using?

[shanemikel]

I'm using https://nixos.org/channels/nixpkgs-unstable nixpkgs. The update was from 78c68f2 to whatever was current yesterday... I think ab6d358

[peti]

I cannot re-produce this. I'm using master at 6c116b8:

~/.nix-defexpr $ nix-env -p /tmp/test -q
ghc-8.0.2-with-packages
~/.nix-defexpr $ nix-env -p /tmp/test -u --always
~/.nix-defexpr $ nix-env -p /tmp/test -q
ghc-8.0.2-with-packages

If this has happened on your machine, then it's almost certainly a consequence of some peculiar override you have configured, i.e. Nixpkgs proper does not do this.

[domenkozar]

This probably happened when we switched haskellPackages to GHC 8.0.2, which is expected for the unstable to happen.

[peti]

Yeah, you are right. This might happen when the user's GHC derivation is defined in terms of haskellpackages.ghc801.ghcWithPackages instead of haskellPackages.ghcWithPackages, because Nix will (correctly) consider ghc-8.0.2 an update to ghc-8.0.1-with-packages. If the user's GHC is defined in terms of the latest compiler, too, then Nix will update to ghc-8.0.2-with-packages instead. So this is all expected behavior, IMHO, no bug in Nix or Nixpkgs.

[domenkozar]

Also why I discourage use of imperative package management, since package version upgrade paths are known to be fragile.

[peti]

What we could do is call the GHC derivation ghc-with-package-8.0.2 instead. Not sure whether that's ultimately an improvement, but it would prevent this particular surprise from occurring.