IOGX Integration

[zeme-iohk]

• Integrate IOGX https://github.com/input-output-hk/iogx with quickcheck-dynamic
• nix develop now drops you in a shell with a complete Haskell toolchain
• upgrade ghc 8.10.7 -> 9.2.7
• Applied fourmolu, stylish-haskell and cabal-fmt

[github-actions]

Unit Test Results

3 tests  ±0   3 ✔️ ±0   0s ⏱️ ±0s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 883d473. ± Comparison against base commit 62c07bb.

♻️ This comment has been updated with latest results.

[ghost]

@zeme-wana Thanks for the PR. I must admit I am slightly reluctant to merge this PR as it seems very specific to IOG's environment. While quickcheck-dynamic has been developed in the context of IOG-funded projects and is currently used mostly within those projects, the "vision" has always been to consider it an open-source project that should appeal to a broader audience.

Let's imagine that tomorrow IOG infrastructure disappears over the night (certainly not something I wish to happen), what would be the consequences for this repository? Would the changes in this PR become irrelevant, or even break?

Another question: What does this PR brings to casual haskellers using nix but not interested in relying on IOG's infrastructure?

[zeme-wana]

@abailly-iohk Thank you for your questions. This PR is very specific to IOG in that it introduces dependences on other IOG repositories, namely (haskell.nix + CHaP + Hackage) and iohk-nix.
While the dependency on iohk-nix can and will disappear in future versions of IOGX, the dependency on the others is here to stay.

If (the entirety of) IOG infrastructure were to disappear overnight, the nix code in this repository would break, including CI and the ability to enter a devShell.

To the casual haskeller using nix, this PR brings a devShell that comes with a complete Haskell development environment, and the ability to easily extend that shell, including the option to change or add new ghc versions, as well as build against a ghc matrix in CI.
The casual haskeller will need to be familiar with IOG infra (Haskell.nix, CHaP, hackage.nix) the moment they want to update the Haskell package set.

The idea of IOGX is to establish a standard way to structure nix code whilst getting most of the common stuff for free (ghc matrices, haskell toolchain, formatters, hydra jobsets, readthedocs site, and more to come) but under the assumption that the repository is built on top of haskell.nix.

There is a price and risk to pay for this dependency. And ultimately it's up to you as the maintainer of this repository to decide if IOGX brings enough of an improvement to justify that cost.

[ghost]

@zeme-wana Thanks a lot for your detailed answer. I am just a maintainer, not the only one. I would be interested in what other contributors think (ping @UlfNorell @MaximilianAlgehed)

[MaximilianAlgehed]

While I appreciate the effort, I'm unfortunately inclined to agree with the point that @abailly-iohk is making here. Is there some middle ground we can strike that makes things easy for people working with IOG stuff while not creating a maintenance burden. Finally, I think the only IOG dependency in this repo is io-sim and that repo is already on hackage - so it's not clear that a tight integration with CHaP etc. is necessary here.

[zeme-wana]

I understand your concerns. Let me to clear a few points:

• Contributors can still opt out of nix and build with cabal/stack, no difference to them.
• This PR is supposed to make the maintenance burden (for the nix code) lighter. The idea of IOGX is to provide a declarative interface to nix so that even non-nix-savvy devs can contribute to it. Ideally we want to make it so that all (or most) of the nix in the repo becomes basically JSON. This is an ongoing effort and quickcheck-dynamic would be an early adopter. If you are interested, the README for IOGX is available here https://github.com/input-output-hk/iogx/tree/readme-v2
• quickcheck-dynamic currently depends on haskell.nix already. Note that haskell.nix itself depends on CHaP and hackage.nix. This PR would replace the current dependency on haskell.nix with one on IOGX (which ofc uses haskell.nix internally), but none of this actually requires any knowledge of haskell.nix, nor CHaP nor hackage.nix. Indeed the idea it to hide all that stuff away.

I do appreciate that haskell.nix is a much safer and more solid bet, having been around for years, while IOGX is still in its early stages.

If the benefits don't win you over then I won't push this further and I will close this PR.

[MaximilianAlgehed]

I'm willing to buy that argument. So long as things keep working without nix - which they should do. @abailly-iohk what are your thoughts?