CI job `NixOS 20.03 stable channel, default GHC (8.8)` is broken

[sjakobi]

See e.g. https://github.com/haskell-nix/hnix/runs/997143369.

There's some background information in https://github.com/haskell-nix/hnix/pull/699#issuecomment-676147573.

[Anton-Latukha]

Well, as I explained - it is essentially really can be removed from the CI.

Currently, it serves "will our dev setup work if we load it with nixos-20.03 channel setup", which is partial response to "can the project be directly integrated into NixOS stable channel", but really it is more "can current dev project state can be loaded with NixOS stable channel setup".

And the question is: why do we care and expect dev setup to load with NixOS stable channel, when in Nix default.nix is a custom configuration with a custom environment, we can load it with any closure we see fit.

I enabled it as easy partial monitoring.

We do not need to keep our dev sandbox setup compatible with different Nix channels, it is a place where Nix loads what devs say it to load.

[sjakobi]

Well, as I explained - it is essentially really can be removed from the CI.

Sounds good to me. My idea of fixing it (https://github.com/haskell-nix/hnix/pull/701) doesn't seem to work, so I'd appreciate if you'd take care of this.

[Anton-Latukha]

Well actually, now since default.nix loads the default local channel by default, contributor, if his/her local Nix default channel is nixos-20.03 - may get this build error.

But again, that because default.nix loads local channel - that does not mean we now must support all Nix channels. We may recommend to use the dev channels and practices, or alternative solution is to hardcode the use of a particular channel, but that would mean local and CI builds would need to download Nixpkgs every time on every build and that takes time and contributor does not control the state of the build.

I see defaulting to default local Nix state more elegant setup than to hardcode particular channel.

• If default.nix would roll on the Git channel - that means people would need all the time every time wait a couple of seconds while Nixpkgs downloads from Git, and then wait much more while closure updates get into the local store and more often wait while deps build locally.

• If we would hardcode channel revision - we would need to actively maintain it all the time.

• I prefer defaulting to devs local defaults, it seems more ergonomic. Dev can control when to update local channel to newest Hydra CI channel revision, which would mean the much more prebuilt cached update passing from the Hydra CI CDN, and that person controls, aware of state changes and so maintains them.

If person is on default stable channel - one always can read default.nix and do nix-build --argstr rev nixos-unstable or any revision they want.

[sjakobi]

@Anton-Latukha, I'm a fan of reproducible dev environments. If we can attain that at the cost of slightly longer builds, that seems like a good trade-off to me.

[Anton-Latukha]

As a conversation starter, please, if topic is important to you, which is shown by raising it - topic starter can, and probably should be willing to give from the start substantive thought to start a discussion, topic starter can/should provide a starting point - contribute effort in analysis, argumentation, and current derived view on the topic and provide more useful information to talk about, so people indeed can talk about the topic.

There are many cases and parts to this question.

[Anton-Latukha]

I want to give the right explanation and impression.

If to express the infrastructure:

Our main dev environment is really a classical Hackage & Cabal development. Proof - we explicitly prioritize it: the only required build for CI is Hackage & Cabal. default.nix is really only just a dev environment for Nix folks. And the default.nix got used in CI for simplicity sake, just because it was the easiest approach to do to somehow-somewhat test project with different Nixpkgs channels.

---

Dialog

Without proper topic starting input and negotiation, I need to evolve the view on the https://github.com/haskell-nix/hnix/issues/700#issuecomment-676550698 topic, in thought (for myself) and/or in writing (for you). I am the person currently short on time/effort pool & satisfied with the current process, so why should I be and pay effort and time to be the thinking hub of the topic I have no strong interest in. As we are developed people, topic starter by starting topic - shows the initiative to be the main analytical hub of the theme. There are a number of pros & cons between using different revision approaches for default.nix, they should be gathered, weighted, and discussed to make a proper decision.

I may also agree to hardcode revision, but that would require a rev update and sync default.nix with nixpkgs to release the project, which is a complication to the project release process, one who wants to release can face several default.nix - Nixpkgs bugs to iron-out, while currently, we do this together gradually. Also the hardware space tradeoff and such, which should be thought about or decided on a whim.

But indeed, the main point of infrastructure difficulties - is and would be going to be the required triangle of integration between the {HNix, Nixpkgs & Cabal} at the same time. We need to develop & find the right approaches and level of compromise to dodge rough integration points in there.