Compatibility woes

[sjakobi]

hnix currently prevents dhall-nix from building with GHC 8.8 and 8.10, and is also the root cause why Hackage's docs builder hasn't been able to generate documentation for it. I think it's safe to say that for the packages in https://github.com/dhall-lang/dhall-haskell, hnix is currently the dependency that causes by far the most headaches.

So I'm wondering what could be done so hnix keeps up a bit better with the rest of the Haskell ecosystem.

@jwiegley, would you possibly consider giving me or one of the other active contributors the necessary permissions to address these compatibility issues more directly? Personally, I would probably stick to compatibility issues and try to extend CI coverage to more recent GHC versions. I admittedly don't know this package (or Nix) very well, but I do have quite a bit of experience with maintaining Haskell packages.

[Anton-Latukha]

When: default.nix: dep: upd hnix-store 0.2 #580 - there is ground for - New release #560

I hope this inconvenience would not happen, attending to it. Already PR-ed some minor dependency status monitoring. Hope from now on Haskell projects would be able to rely on HNix being on the time and showing-up ready.

[jwiegley]

@sjakobi As I did for @Anton-Latukha, you now also have maintainer rights and can assist with keeping hnix working for others.

[Anton-Latukha]

@jwiegley Thank you. I've wanted to ask you to add others. You advertised Gitter - do you appear there? I would probably IRC then. We are able to make a new release - see Report #560, don't forget we have no rights to Hackage, so please remember - releases is still your thing. Also would be good if you say some thoughts on some discussion issues created.

@sjakobi I am happy to work together. There is work to do. I've seen you a good community member. We should prepare and automate the flow, and make documentation, before we would merge the evaluation of Nixpkgs, as after that we would not be able to automate easily, discuss questions and arrive to structural responses (like should we merge HNix&HNix-store, where to put documentation and what we would do) prepare to direct the community flow - that is the main questions that I see.

I already raised most important points and questions for me in posts this week - so the stage is yours.

I would ask, please, raise and participate in dialectic discussions.

There is efficient principle - idea is a Report rule to keep people on topic, in PR - on code, in Reports - on the theme, and so we would have proper thoughtful philosophical grade discussions that arrive at the truth. I plan to layout and explain dialectic basics in the introductory docs, since people seem to not know this efficient art that is ~2500 years old.

I am Anton, I love philosophy and mathematics.

Please leave me your contact, so we get to know each other and collaborate directly.

[Anton-Latukha]

@jwiegley would you be kind to promote @sorki. I already knew him as a great community member, we bumped a couple of times with him in Nixpkgs and in HNix gitter for last two years, and I perceived - he is one of the most genuine pretty efficient guys in the community & he has proper qualifications & he did already a number of PRs into both hnix and hnix-store. I already approached him, mailed back&forth with him yesterday and before yesterday, if he would be interested to maintain and bear responsibilities if I ask you, and he does, I've planned to talk with @sjakobi next, and then talk with you about to promote them. Thanks for understanding.

[Anton-Latukha]

Cool, I am happy to be beside @sjakobi he seems a great contributor. Now we would definitely #551 (comment) and we definitely would have a good relationships with 👍 DHall. Since I am a former DevOps I am personally also interested in DHall. As any professional and DevOps I needed to learn, know and remember a lot of programming languages and configuration DSLs that many now DHall allows to import-export in one easy to program/reed language - that is much more efficient and tidy approach.

[jwiegley]

@sorki Welcome to the maintainer role. :)

@Anton-Latukha Just let me know what commit you'd like to release, and at what version, and I'll try my best to push to Hackage the same day.

[sjakobi]

@jwiegley Many thanks for the invitation! I'm glad that you permit other people to become involved in maintaining this project while you focus on other things. I know other projects that I wish would handle maintainership similarly! :)

@Anton-Latukha I hope I haven't promised too much in the issue description! :) Indeed I currently plan to focus on dhall-haskell's needs, which AFAIK are stability and support for recent GHC versions and other dependencies.

While I am curious about Nix and hnix internals, I also tend to become involved in too many projects at once, so I can't promise to contribute much to new feature developments etc.

@Anton-Latukha Do feel free to contact me via the email address listed on my GitHub profile. Although for most discussions I prefer to have them in a public and asynchronous space such as GitHub issues where other interested parties can easily chime in. But there are always exceptions. :)

[sorki]

Thank you for the inviation @jwiegley and for all the work you did on this project!

[sjakobi]

Let's keep this open until we support GHC 8.10 too.

[Anton-Latukha]

@sjakobi

It closed automatically because I attached it to #580, since to that merge most of compatibility issues got solved.
BTW some dependencies still not merged: #557, and we now additionally need aeson update.

---

I would ask, please, just open a Support GHC 8.8/8.10 Report for this question. That is kind-of different topic from what was raized here, let us atomize the topics. It is strange even to remember to open this DHall compatibility Report to discuss GHC 8.10, while new GHC is a major Haskell theme in itself. You can link this thread there and state that you would not close this issue until 8.10 support, that is understandable, but lets discuss GHC 8.10 related things in a separate thread.

[sjakobi]

Fair enough. I doubt that we'll forget GHC 8.10 support, so we probably don't need another issue.

[Anton-Latukha]

I think that we should put minor releases frequently.

For my view

• receiving and solidifying the internal consistency with hnix-store is itself enough for minor release
• nix packages cleanup, now we have proper versions of dependencies in Nixpkgs infrastructure
• all Cabal package dependencies updated

it is a pretty great minor release with a lot of done #560.

We would resolve most dependency issues with this release.

And to not propagate the dep issues downstream - update releases need to be frequent.

And GHC 8.10 support - deserves minor release in itself also.

We would make a release, CI will or will not go into it. But for monitoring {8.6.5, 8.8.3, 8.10.1} in master and PRs - that does the CI, so I prefer to merge/have CI before/during GHC 8.10 work/support - it is easier to check that GHC 8.10 also builds PRs and that it builds in different conditions.

[jwiegley]

I'm good with frequent minor releases.