Please, provide in CI the classical Cabal build

[Anton-Latukha]

Long story short.

To see that something is the upstream Nixpkgs problem - classical Cacal CI build is needed so we are able to know when Nixpkgs builds have issues does classical Cabal+Hackage builds properly.

I already reached the Travis CI design constraints, since Travis CI has single script: process thread - Travis CI can not do two different build systems.

If we continue using Travis CI - it becomes fetters on the project automation growth, the level of heuristic complexity of its configuration would increase drastically, since its design forces to mesh-in and cross-dodge between different build processes (systems) inside a single script: thread. That would turn the configuration into unreadable, brittle code from currently elegant transparent code. Travis CI is just not designed for two different build systems.
Of course, Shell is Turing complete and project can offload everything into side-car code, but that means we start to write own CI platform, while CI itself required to do it in the first place.

And to make any migrations and keep with responsibilities of growing the project, the level of permissions should be raised to taken responsibilities and work, which I started to discuss in #636.

I kept our Travis CI setup working right with yesterday's sudden Nix installer release, and its changes and its current "caveats", and made a refactoring of configuration so it is in a good state now.

The community needs to be able to monitor, be helped to understand the Nixpkgs inconsistency problems when they arise, we need CI extension/migrations.

I want and it is seen - took responsibility to work, extending our processes and automation for everyone to have a smooth going contribution experience, I need to be given permissions to proceed.

---

I am a proponent of the sticking to Nixpkgs as much as possible for the project, but I would build a solid case of contra Nixpkgs here to be realistic:

Prelude: Currently, CI uses Nixpkgs store for all builds, 5 different GHC versions and so their Nix closures {GHCJS, 8.4.4, 8.6.5, 8.8.3, 8.10.1}.

1. By current Nixpkgs design, the Nixpkgs really consolidated over particular GHC that is the default in it, currently, it is 8.8.3.
   This design towards one version - results in less use, maintenance, eyes and hands on other GHC versions and so all their store branch consistency in Nixpkgs, and source structure and community treating them as additional functionality.
2. Nixpkgs upstream practice to dodge upstream progress with creating side-packages for new releases - results into that Nixpkgs constantly seduces itself into dodging the Hackage progress, and so downstream gets inconsistency of newest GHC version subset in Nixpkgs.
3. Lack of upstream automation results into lack of hands for upstream manual maintenance.
4. {3,1,2} would constantly resolve into that graph trees of non-default in Nixpkgs GHC versions would be constantly sacrificed to keep default Nixpkgs GHC graph consistent, community forgets to account for all GHCs, default GHC would always get a maintainers priority, and dodging upstream and overall side-packages practice allows to keep default GHC graph working on the default packages consistent, while breaks all other GHCs graphs consistency, and so those branches now need switch/make side-packages and so they need overrides of packages to side-packages. And as stated overall the consistency of non-default Nixpkgs GHCs is less then ideal.

---

Good thing - we are the very specialists that can debug, work and automate Nixpkgs, specialists that in time can change/improve something in Nixpkgs solely by making HNix a reality.

---

This Nixpkgs situation results in that the project frequently hits the Nixpkgs upstream package version inconsistencies of the store, like companion got in #635 (comment)

An example of nearest empirical proof of the situation and statement is seen in: https://travis-ci.org/github/haskell-nix/hnix/builds/701250357, due to need of one current Hackage version - all GHC graphs got broken except the default GHC due to current Nixpkgs design. Good that Nixpkgs is mostly the freshest store around.

[Anton-Latukha]

Also related: #593 #581

[sjakobi]

@Anton-Latukha To be clear, do you suggest setting up cabal-based CI in addition to the current nix-build-based one?

[Anton-Latukha]

We cannot do anything currently, since that requires registering the account/repository in other services.

Nix build and classical Cabal build are completely different processes, currently env:, before_script: and script: in .travis.yml are for Nix build only, so to proceed we would need to cram-in the classical build into it, or offload everything to a hierarchy of side-scripts, which is hardly a good CI automation practice. The cause of that is - Travis CI is not designed for such abilities.

I want to keep the abstractions pure, build.sh does not have Travis-related code, it addresses the builds for any CI.

[Anton-Latukha]

I basically wanted to address your problem that you got in neat-interpolate PR.

Since I know and I do not expect from all people to somehow intuitively know all Nixpkgs current situations and code. And to help even myself, by making the causes more transparent, so we all can see, the PR is right, because build Cabal+Hackage works, so what we see is Nixpkgs inconsistency. When that automation would be done and shown - that would be intuitive not only for me, any Haskellers contributor would understand that the code is right and that Nixpkgs needs to be fixed. So contributor sees and ensured that it is the Nixpkgs problem - contributor/maintainer can straight report it upstream or/and sort-out help with it or debugging/resolving it.

Also even more - we need to test the Cabal+Hackage build since it is the default in Haskell ecosystem, and we release the project on the Hackagee ecosystem first. And many people would use our project/package right from Hackage. Also, it is half of the way towards including testing for Stackage, which should be optional build to PRs to monitor of course.

Project status and consistency in many build stores can be monitored and ensured only with CI automation. Cabal+Hackage is important build for the project, Stackage to monitor it, Nixpkgs for its reproducibility, features, and as the main agenda of the project.

[sjakobi]

I'm aware of other projects that use Travis with multiple build tools, but it does of course make things more complex.

Right now I don't see a huge need for CI with cabal, and I'm somewhat wary of increasing complexity even more.

Stackage also acts as a CI with recent package versions. (If you want to get the Stackage notifications for hnix, I can set that up!)

I think we should use proper version bounds to prevent build failures like #651.

Once we have proper upper bounds, we can also use https://packdeps.haskellers.com/feed?needle=hnix to be notified about outdated dependencies.

The main problem in #635 is just that it's unclear how to make the Nix setup use a specific dependency version. I suspect that that can be fixed in the Nix code. It shouldn't require additional CI.

[Anton-Latukha]

Hackage, Stackage and Hydra have their own CIs, they monitor releases. To monitor our own PRs and master we need own CI builds for it.

Shield to Stackage status is beneficial. Just as Nixpkgs Hydra CI that put recently. But those alerts are backwards, when we release the project - they test and report status. We need own CI processes to be aware of those dependency constraints in Stackage so we solve them before we form a release in the first place, otherwise we would need to release a new release to replace-fix the old release in stores.

[sjakobi]

Let's wait and see first, I'd say. If users are unhappy with our dependency management, I'm sure they'll tell us.

[Anton-Latukha]

HNix belongs to the two worlds Hackage (Cabal) and Nixpkgs (Nix) - they are very-very different worlds - the semi-constant build problems are inevitable for this project.

Releases are releasesm, they should work so people use them, otherwise the community would look at the brokenness and turn around. Like people that decided to try Nix turned away from it, for years. because Nix installer was not working.

Moreover, Stackage.

1. I do not want the package to be in the Stackage to be broken most of the time.
2. Many people would look on it, at our unaware brokenness there, and think of probable some unprofessionalism of the project.
3. And they would not be able to try it on Stackage or rely on it, so that teaches them of project brokenness and not to use it. And we want to grow the community.
4. And would say to others that the project is unstable in their experience, which is negative to the growth of the community.
5. And the Haskell community would constantly report to us that we are on Stackage but not respect the Stackage. Like we literally got today: hnix-0.9.0 failing to build (broken by repline-0.3.0.0?) #651.
   HNix works for Hackage&Cabal, works on Nixpkgs/haskell-updates, project and its repoline dep works fine on both those very different and main for us platforms. So who would have thought or has the time to contemplate all possible variants. Now Stackage reports to us that this dep does not work in their store, so someone released HNix there and our release now is broken there and we need to maintain it. Why we need to maintain it I put in 1-5 and in Please, provide in CI the classical Cabal build #653 (comment)

How we would be aware of, solve and juggle all their different dependencies requirements without monitoring for them, so in blind? Are we Zatoichi level?

[Anton-Latukha]

Regading: #653 (comment)

1. I think we should use proper version bounds to prevent build failures like hnix-0.9.0 failing to build (broken by repline-0.3.0.0?) #651.

We are not able to test all version bound cases, we can use the own CI, platforms/stores CIs, our different CI builds for those stores. The thing is that the stores introduce their own design&structural problems, so we need to test for them explicitly.

2. Once we have proper upper bounds, we can also use https://packdeps.haskellers.com/feed?needle=hnix to be notified about outdated dependencies.

I probably should not mention obvious, it is already monitored on the front page shield.
I myself subscribed to the RSS to be notified on changes. But packdeps.haskellers.com seems to not account for some cases of package updates, because from #557 we got several package updates, for example, packdeps.haskellers.com service, badge or feed somehow never notified me or in the badge (I check it from day to day) to update the haskeline.

Also #558 as a result of packdeps.haskellers.com not respecting the deprecation of versions, but CLI tool can respect them, so I created an upstream report, I do not know when who (Snoyman, his team, me) would address it. I try not to link to reports between semi-competing projects, especially when I maintain them and interested in the progress, I try to not involve those things, feelings, levers into requests and development processes.

3. The main problem in Use neat-interpolation instead of interpolate #635 is just that it's unclear how to make the Nix setup use a specific dependency version. I suspect that that can be fixed in the Nix code. It shouldn't require additional CI.

It is a feature of Nix by design. Dolstra very deliberately made it to not care about package versioning and to roll on latest stable releases. In fact it is one of the places I strongly agree with his idea.

And to be realistic, it is probably pretty impossible to avoid that design ideas making the purely functional lazy OS management system, since otherwise one would need to make it in the not proper purely functional lazy way.

The thing is the explicit dependency bounds are the imperative process. And having the only one canonical compiled release that pretends that dependencies and reerse-dependencies does not update and should be always able to work with it properly, and then stored somewhere as that binary and then installed and expected to work - is also imperative paradigm.

Nix basically always takes unique inputs, always recursively downloads all needed sources of all dependencies, purely assembles everything together purely from their source code and in that way tests it all, does it builds/passes tests on the newest versions, and puts a hash on the unique build. And package uniquly links only with those same packages it was compiled with. Also Nix can (for now it is a very weak feature) fallback onto previous package releases, recipe version, or just previous working chain of releases, if that practice is properly developed then all Nixpkgs would always or straightly work, or bend itself into a working compatible binaries state, so theoretically it is easy to make the resulting binary store coerce consistently to work all the time.

So from the get-go there is no regard to dependency bounds in Nix. Even more, the dependency bounds not really needed in its design and use.

Dolstra deliberately created it so, Nix strives to always get the latest released stable versions and use them. That works very great in the majority of cases, that also works great in Arch Linux and Gentoo also. And NixOS transactional nature keeps it robust and allows people to update/switch only into consistent revision.

Brittleness of build graphs is inherent from the purely functional nature, but as I sad - proper fallbacks are possible in every case (and Nix store is multigraph) so it allows to keep brittles inside the CI, and CI attends to it, and uses get exposed only solidly working store. In the ideal case, if HNix becomes reality and fallbacks and CI created.

Dolstra deliberately made it forcing the Free Software progress and consistency and so Nixpkgs community irons-out upstreams into that consistency and portability. People still did not understand that Nixpkgs is a universal quality stamp (build in pure environemtn, purely functional builds directly from sources, referentially transparent, reproducible) and testing CI for Open Source ecosystem. If pure build of the project needs manual patching inside Nixpkgs - it is always a direct arrow to the related problem to solve in the upstream project.

Ability to bend the Nixpkgs from the proper state of Open Source structure, into "currently upstream project demands it only work this way", the overriding of versions is an additional feature. 50% (2 of 4) of freedoms of Free Software is the 1) ability to distribute software however you want, and 2) use software however you want, and upstream asking you to distribute and use it only particular way does not correspond with those cornerstones of Free Software. And of Unix philosophy, being composable and compatible with other utilites. Project should know the trues - that they do not know, how their project is used and where and how (as HNix releases on Stackage). So they should strive to support virtually all cases and platforms, and most importantly the current state of Open Source ecosystems. If something - they can at least say, look - it works in line with current ecosystem, do you really expect the all old software releases be compatible with our project.

That is what Nix addresses, distributivity, quality and consistency of the current ecosystem. Striving for proper state of an ecosystem may be idealistic, but it pushes all people into the right direction, and brings a lot of good to Open Source ecosystem, and it works surprisingly well for its idealism.

[Anton-Latukha]

I wish the internal Nixpkgs package management processes change/improve, then required package dependencies management would be bearable.

That is what I talked about in #653 (comment) second part, about Nixpkgs.

[Anton-Latukha]

Yes, hence its paradigms, Nix seems very cryptic, and is cryptic and needs to be adjusted, to since it does not look and really is not like all other software management software.

But we can not break from Nixpkgs in any case, the sole purpose of the project is Nixpkgs.