Migrate --nix support to use haskell.compiler.ghcXYZ attributes instead of haskell.packages.lts_X_Y

[peti]

The haskell.packages.lts_X_Y package sets will disappear from Nixpkgs in the foreseeable future and stack should not rely on them any longer. Instead, please access the appropriate compiler using the haskell.compiler.ghcXYZ attributes instead. http://permalink.gmane.org/gmane.linux.distributions.nixos/20505 has more details about the motivation behind that upcoming change.

[YPares]

Ok, so what would be the cleanest way to get the required GHC version from the LTS?

[mgsloan]

I do not see the reason for this change, and it will break existing stack versions and build configurations. This message seems to be frustrated with a variety of non-fundamental, fixable issues. Please consider this more carefully.

If changes to nix / nixpkgs become too much of a maintenance burden, we may need to consider whether stack will continue having first class support for nix. I am not sure how the nix support would need to be adapted to support this, it may not even be viable to adapt it.

1. Stackage does not "maintain" any of its LTS releases. Rather, the
   Stackage volunteers compile a list of package versions, test and verify
   them to the best of their abilities, release that list, and then they
   never touch it again.

How about bringing up this issue on stackage, or integrating the nix feedback into the curation of stackage?

2. Following LTS strictly may deprive us of important security updates.

Ok, this seems to be more like "I don't want stable package sets". Follow lts non-strictly if you do want security updates.

3. Stackage Nightly is not a stable package set.

So we do want stable package sets! :)

This seems like an impedence mismatch between how nightlies have been exposed to nix users. If "haskellPackages" is always the latest nightly, then yes, you shouldn't do that if you want reliable builds.

If you want something stable, use lts. If you want something unstable, use nightly. It's that simple.

4. Stackage releases come out only after a complete test build of all
   packages has succeeded. Unfortunately, those tests don't always catch
   all issues we might run into, because we compile packages in a different
   environment.

Ok, lets work with you guys to curate stackage via feedback from nix.

My summary of the issues covered is:

1. Wanting snapshots to be more stable in some ways and unstable in others (security)
2. Nix predicate of success /= stackage predicate of success, and you are understandably frustrated with maintaining the mismatch.

IMHO, these reasons are not sufficient to justify this. That said, I am not a nix user and I don't experience the maintenance burden. These are indeed tricky problems, their resolution isn't trivial. However, I don't see how dropping stackage makes (1) any easier, and we can collaborate to address (2).

Please keep in mind that the stackage process is not set in stone, we are still experimenting with it. Please help us refine the process rather than ditching it.

[mgsloan]

Ok, so what would be the cleanest way to get the required GHC version from the LTS?

The snapshot specifies a compiler version, so stack knows that once it's loaded. Do you need to get the GHC version outside of stack itself?

[peti]

@mgsloan, to the best of my knowledge, adapting Stack to use the compiler attributes rather than the (obsolete) LTS package set attributes should be a harmless change that won't pose any serious problems. I realize it's inconvenient having to make that switch, and I am sorry about that. We did not take that decision lightly and there was a discussion with various Stackage team members beforehand. Alas, things turned out such that the level of support Nix used to offer seems clearly unsustainable, hence the change.

[YPares]

@mgsloan Nope, I meant within stack's code actually.

[mgsloan]

Gotcha!

asks (envConfigCompilerVersion . getEnvConfig) :: (MonadReader env m, HasEnvConfig env) => m CompilerVersion

[YPares]

Okay, it required a bit of working around as the monad outside the nix-shell wasn't an instance of HasEnvConfig, so I submitted a PR so people may review the solution I'm proposing: #2270.

[YPares]

@mgsloan Ok, so it isn't fixed, sorry.
I can't use setupEnv to get the wanted GHC version because it expects GHC to be already installed.
And as I said, I'm outside any HasEnvConfig monad.
Any idea?

[YPares]

@mgsloan Okay, I found another (simpler) way. I think it's good now.

[peti]

LTS package sets will disappear from Nixpkgs master this week. We'll keep the haskell.packages.lts_x_y.ghc attributes around for a while though to remain backwards compatible.