Closed Anton-Latukha closed 4 years ago
Thanks for asking! Personally, I don't have any feature requests, but I would love to see a release that is compatible with the latest prettyprinter
and GHC. That would greatly simplify building and packaging dhall-nix
.
BTW I just attempted building hnix
from Hackage and got this:
Nix/Expr/Types.hs:76:3: error:
‘showsPrec1’ is not a (visible) method of class ‘Show1’
|
76 | showsPrec1 = showsPrec
| ^^^^^^^^^^
@Anton-Latukha: The number one thing hnix
can improve upon would not be a specific feature, but rather just a regular release cadence. The last release to Hackage was almost a year ago
@Gabriel439 @sjakobi
Chatted with John, he basically stated that HNix does not build for all the conditions he requires.
I would investigate that and tend to it, and then would form a release.
@Anton-Latukha: While you are looking for ways to improve hnix
, codifying those supported platforms/environments in CI would help prevent this from recurring in the future. For example, for Dhall we use CI to ensure that no pull request is merged that breaks any supported platform or any supported GHC.
@Gabriel439
I know, I know.
It can be quite hard to squeeze into free Travis norms what is needed for Haskell, but that is understandable for free
.
Especially when Travis, AFAIK, failed miserably some times. Hope they fixed their networking issues for nodes.
Overall, yes, property testing and CI.
What CI would you recommend currently for free Haskell projects, I see you use both Travis and Appveyor.
@Anton-Latukha: I think it depends on what John needed to support before releasing. It's not clear to me if that means operating systems, GHC versions, GHCJS, etc.
@Gabriel439
Of course - I just asked a pretty stupid general question.
@Anton-Latukha: Probably the biggest constraint is whether or not CI needs to test Windows or OS X, since build machines for those are harder to come by. We currently use AppVeyor for Windows builds and Travis for OS X builds since they are free. For Linux you can basically use any CI provider, but in this case I pay for a Linode VM which I use to host all Dhall-related infrastructure (i.e. all of the *.dhall-lang.org domains), so I reuse that to host Hydra for Nix-related CI so that I can use more parallelism and more efficient caching to test a wider range of GHC versions on a budget.
For testing OS X and Windows platforms we use stack
. The main reason we don't use Nix for either platform is that Nix only supports building release binaries on Linux (and even then it's still experimental).
So the basic summary I can give is:
For testing everything other than cross-platform support: Nix + Linux is best in my opinion
... because you get much more control and intelligent build caching, which is usually where most CI solutions fall short
For cross-platform support: stack
+ whatever CI provider provides free builds for that platform
Also, if you ever can pay for your own NixOS VM and you want to reuse the setup I built, you can find the NixOS configuration for dhall-lang.org here:
Thank you. Very to the point. This information worth a dedicated article (blog post) in itself, but may not worth an effort of the high-quality article, as it is the current state of affairs.
@Anton-Latukha: You're welcome! 🙂
@Gabriel439 Would you allow me add https://github.com/dhall-lang/dhall-haskell/issues/1678#issuecomment-592960057 as your quote in my docs?
@Anton-Latukha: Yeah, definitely! 🙂
@Gabriel439 Thank you, here is where the quote is used https://blog.latukha.com/haskell-notes#org05bb15e Page is large, it would load for a couple of secs and then center on the quote. Also the Org-mode HTML export changes the anchor IDs around, so on next publish it would be other URL ID.
Also there is a new HNix release!
I am kinda in search, what task to pick next in HNix.
What you consider the shortcoming of the HNix that can&should be solved?