Build in nixpkgs broken because neat-interpolate dep is to new for stack release

[maralorn]

As of version 0.9.1, the hnix build in nixpkgs does not work because of the constraint neat-interpolation >=0.4 && <0.6, cf. hydra log.

The problem is, that we get an older neat-interpolation ==0.3.2.6 from stack.

I could successfully compile hnix 0.9.1 with a jailbreak, suggesting that the lower version bound of neat-interpolate is to strict. But hnix tests are disabled on nixpkgs, so there might be danger lurking there.

@sjakobi, @Anton-Latukha, are there any semantic reasons for not allowing >= 0.3.2.6? If not could you make a revision loosening that constraint?

[sjakobi]

are there any semantic reasons for not allowing >= 0.3.2.6?

See #635 (comment). This behaviour change affects our test output.

The problem is, that we get an older neat-interpolation ==0.3.2.6 from stack.

You can find some info on neat-interpolation's status in Stackage here: commercialhaskell/stackage#5119

It's unfortunate that neat-interpolation was restricted for such a long time.

Today, Stackage nightly contains the latest neat-interpolation.

Could you use a newer neat-interpolation in nixpkgs too?

[maralorn]

Oh, sorry, I didn‘t see that. Not a problem then, I will override it in nixpkgs.

[sjakobi]

Thanks!

And apologies for the trouble. If I had been aware of the implications, I might have held off on switching to neat-interpolation until a compatible version was more widely available in the ecosystem.

[Anton-Latukha]

Great that this resolved so quickly.

I only got to this thred.

That is the thing, Simon, we can not know what is what in what platforms. It is good that Nixpkgs is a very fresh store. But honestly probably other software stores are not really FP, so they would autoroll only when they can, not like FP Nixpkgs that rolls for us by default even when builds fail.

Honestly, I do see only this solutions:

• To have an automatic build test base to catch when we do PRs or before release testing.
• We should prioritize development and new versions over old implementations, until we would claim some "1.0" as "production-ready", we should employ Haskell strategy and break frequently until the project starts to work and be ready to be used in productions.

Both of them - first would test and show cases, second - would require us to move forward.

Honestly, until we understand that project really ready for some use - we should not think about software stores, besides Hackage and Nixpkgs - since it is the project field. Because if we would get worried that we break stores - we would stop the progress when the project needs it, and unfinished project with old versions of dependencies would even more easily would be ported by everybody and spread to even more stores - and then we would never would be able to move project without breaking some of many stores, which would require to be our explicit decision tp take responsibility of breakage, and bug reports would come in from those stores - while what we need is progress for the project until it is ready to be used. So we indeed must break often to new versions and center only on Hackage and Nixpkgs until the project reaches "1.0", moreover since Hackage and Nixpkgs keep fresh Hackage package sets.

[Anton-Latukha]

I am a hypocrite for not checking the HNix earlier after the release.

And I see that the second time you are faster to it then I. I wait a bit when the version would arrive at Nixpkgs.

@maralorn you probably know definitely: how frequently Nixpkgs syncs to new Hackage versions?

We can sort the responsibility. Do you interested in supporting HNix in Nixpkgs, as you already did two times, or you think it is better for me to get info and be on schedule and monitor it after release?

[maralorn]

I have a few points to make:

1. Don‘t compromise development speed because of lagging deployment conditions. Open Source development has to many friction points already, don‘t let nixpkgs keep you. Besides as long as there is a valid build plan with the most recent versions on hackage, fixing the build in nixpkgs is really easy. And at least for a project like hnix, I think it won‘t be a problem to find someone to maintain that. (Of course loudly announcing to some maintaining person if you advance some bounds beyond newest stack lts, would be really nice.)

2. The haskell-updates branch on nixpkgs advances based on the newest hackage snapshot every night at around 2:30 CE(S)T? cf. the commit history of the hackage-packages file. This branch gets then tested, issues get resolved manually (if anyone cares) and that branch get’s merged into master usually once per week (normally on Friday evening). Which versions to get from stack get’s manually bump normally a few days after the latest stack lts release.

3. Don't beat yourself up @Anton-Latukha I am cheating. hydra exposes prometheus metrics. I scrape them once the hour by my personal monitoring infrastructure. So I actually receive an alert (on my phone, but it's silent) for failed builds (of a select number of packages I care about) within 2 hours of a fail on hydra.

4. I am not even sure, why hnix is in that list of packages I care about, I think it's because it's a dependency of obelisk. Anyways I am glad to help, but allergic to reponsibility. Sometimes I can be very quick, but sometimes my other duties will keep me from intervening for days. So please don‘t count on me. But of course feel free to mention me wherever applicable. I will normally answer in due time.

[sjakobi]

Thanks for the nice feedback @maralorn! :)

1. (Of course loudly announcing to some maintaining person if you advance some bounds beyond newest stack lts, would be really nice.)

I wonder whether we should try communicating dependency changes with more detail in our changelog. Would that be helpful to you?

[maralorn]

I wonder whether we should try communicating dependency changes with more detail in our changelog. Would that be helpful to you?

That's an interesting question. I think it's a very good idea, and when I know hnix does this I might remember to look in the changelog.

But honestly I normally don‘t expect library authors to be so considerate. So normally I would try quite a few other sources of information, e.g. git blame on the cabal file before resorting to such desperate methods as looking into the changelog. ;-)

(That being said, for similar but different situations, changelogs are very important for distro maintainers, so yeah, putting version informations in there, especially everything related to API changes (in your package as well as the deps), is very important.)

Anyways this issue was not hard to debug and your answer was very quick, so don‘t worry to much about it. But I think if in the future you have a change that you expect to need manual intervention in nixpkgs highlighting @Anton-Latukha and me for a heads up would be very considerate.