Remove overlapping [From,To]JSON instances for NExpr

[sjakobi]

…for compatibility with aeson-1.5.3.

Closes #690.

[sjakobi]

I don't understand the error: attribute 'neat-interpolation_0_5_1_1' missing, at /home/runner/work/hnix/hnix/default.nix:229:55 failure with Nixpkgs, Linux, additional / NixOS 20.03 stable channel, default GHC (8.8).

[Anton-Latukha]

As I pointed-out in: #689 (comment)

default.nix dev env is not able to build inside nixos-20.03 channel, but that is of no importance to the release process.
In reality nixos-20.03 store currently does not hold any 0.9.1, it holds hnix 0.6.1.

And in #698 (comment):

It is a reminder for us.

In reality nixos-20.03 currently does not hold 0.9.1, it holds hnix 0.6.1.

While Nixpkgs by default dodges upstream packages - projects to follow several Nixpkgs channels therefore would be required to constantly construct and maintain configs for them, for default.nix to be able to be built in both.

More than testing for nixos-20.03 for dev - we need to have an integration test.
More than maintaining nixos-20.03 dev environment - we need to backport our project versions by themself inside stable channels, if that is possible.

Lets keep nixos-20.03 the way it is, soon we would sync with nixos-20.09 release.

The reason it popped-up unexpectedly, is that somewhere working between several repos, trying make haskell-with-nixpkgs work with custom nix-store monorepo, and rebases between then - in rehashing things I missed a line rev passing into nix-builds, so during last merge I again seen that and fixed on the spot. It is #698 (comment)

I've previously missed to put rev into build commands, so now we have proper true build fails for nixos-20.03 😎.

But there is no biggy.
There is no deep sense for default.nix tracking the current nixos-20.03, especially if Nixpkgs community and we not backporting to it. And moreover - we probably should not support stable NixOS channel in default.nix, since our default.nix is our project build env, it does not relate to NixOS.

About backporting

While stable channel nixos-20.03 was more or less maintained and received backports in the last 4 months, now it is that time of the year when NixOS community and maintainers srop caring about nixos-20.03, since nixos-20.09 demands all effort focus.

We can decide to comply to nixos-20.03, backport to it, but in 1 month nixos-20.09 should be released, and in 2 months nixos-20.03 is officially deprecated.

NixOS stable releases have a "month support overlap" and then older release essentially gets deprecated (not maintained much) and everyone and their unkle encouraged to move to the current release, it is essentially employed to constantly evolve and save the most limited in Nixpkgs community resources - the maintainers' effort and concentrate them and everyone on the development of what is important currently, and strategy works good also by design of the system, rolling from one stable release of NixOS to next - is technically a solid FP process.

Conclusion

default.nix is a dev environment, and from Nix perspective, it is strange to demand from dev env compliance to NixOS stable channel env, when dev environment is obviously a development environment, default.nix is not a deployment environment from Nixpkgs perspective, Nix design also leans toward projects and their packages having own env and own closures, is it custom default.nix or is project is part of Nixpkg. Nix by itself does not demand any compliance to Nixpkgs. Compliance to Nixpkgs is obviously demanded when we want to integrate project into Nixpkgs.

NixOS 20.09 would arrive, it would sync-up to our project, in half a year of nixos-20.09 - haskell-with-nixpkgs and HNix CI processes would evolve further, then we would actually track did project integrates into Nixpkgs master, and did project integrates into Nixpkgs nixos-20.09 in the way that Nixpkgs does that. But that integration does not relate in any way to contents of projects default.nix, and relates to everything hnix.cabal.

[sjakobi]

@Anton-Latukha, are you suggesting that I ignore this CI failure!? I'm not very interested in Nixpkgs internals.

And what should I do about the Nixpkgs, macOS / NixOS-unstable, default GHC (8.8) (pull_request) failure? It looks unrelated to my patch.

[Anton-Latukha]

Well, if Nix install is not successful, that is not our thing - restarted the build.
IDK why people love so much to exploit CDNs also for installations in DevOps CIs. Especially regarding the design of Nix.

Official Nix CDN install fails quite from time to time. It hits limits sometimes, nodes can not reach it for some reason, etc.

Also, yesterday Cachix part of the day was unresponsive, I've reported about that, but I think Cachix service just has some struggles with scaling the service, free tiers for Open projects are already kind enough, most probably they are the majority of the reason.

---

That is how GitHub CI fro Nix is done currently by everyone, and how installs and actions are developed, how CI configuration is suggested and how everyone does GitHub Nix CI, currently.

In reality, Nix and Cachix install and cache maintenance can be optimized, abstracted away, by constructing proper more advanced GitHub workflow automation that currently has no implemented comparisons. We should automate this (Nix & Cachix installation and Cachix cache download) thing away; at some point, In due time. At some point I plan to work on it in haskell-with-nixpkgs, but, CI is already much more ergonomic and faster than before, much faster to startup nides, much more parallelism (much more nodes), Nix installer gained overhaul, CI is much faster to run install actions, the builds themselves run much quicker due to much more powerful nodes, than further shaving off seconds from CI and resisting occasional one-off fails, - there is many more more important things to address.

[Anton-Latukha]

The only thing I regret about GitHub CI - is that it is impossible to mark commit ✔️ if any of optional builds failed, so any one optional build essentially always would taint the symbol of the total state.

Currently, there is no way to address this in GitHub CI.