Packages marked as broken should come with an explanation

[sternenseemann]

@cdepillabout

We currently don’t have any infrastructure to correctly mark packages as broken from Haskell package sets based on the different compilers. (Although this would of course be a nice improvement if we could do it.)

Note also that there’s an issue about this. I’m planning on tackling this after the next cabal2nix release is finished.

@amjoseph

It’s been a while since I was writing Haskell code on a regular basis, but I see that cabal now has something analogous to Rust’s Cargo.lock. Are Haskellers simply not using this facility? Although I find that Cargo.lock makes rust projects more brittle, it is also the reason why rust programs always seem to build correctly on the first try (as long as you aren’t trying to modify them, of course!)

The comparison between Cargo.lock and cabal freeze files is inaccurate. Cabal requires what you can call “local consistency”, meaning that exactly one version of a package may be available at build time. This has the practical implication that a “globally consistent” package distribution is possible, i.e. Stackage and nixpkgs’ haskellPackages. A globally consistent distribution has the following practical advantages:

• Having the only versions of a package available explicitly packaged and not guarded by a lock file allows you to effectively react to security advisories and to patch critical bugs. This point has been made well in “The modern packager’s security nightmare”. The point kind of makes itself looking at all the crates with advisories we use because of lock files.
• I strongly believe that our current approach yields a higher quality: We are running tests on every package where it is possible (something buildRustPackage does not), having greater confidence it’ll work correctly at run time, and have a lot of code working around specific problems. A lot of them are self afflicted of course (version incompatibilities, overzealous constraints), but a significant portion are workarounds for compiler bugs, fixes for a package’s interaction with the unusual environment that is Nix/NixOS. Additionally, these are benefits inherited by downstream users for free where in a buildRustPackage approach you’d likely have to add the same workaround in every individual derivation.
• Most importantly of all, this would certainly be unfeasible in practice: Building some Rust derivations is already painfully slow, but GHC performs even worse than rustc. Rebuilding the same dependencies in different derivations all over again (as happens with a buildRustPackage approach) would waste CPU time and make rebuilding e.g. pandoc a painful ordeal. Providing binary cache for developers’ downstream projects would also not be possible which has been a killer feature of the nixpkgs Haskell infrastructure from day one (in fact it got me and many other into Nix in the first place).
• Related to that, we can do expensive build configurations for downstream benefit, e.g. build profiling information, so no one has to rebuild their entire dependency closure to profile an executable.

I wouldn’t be opposed to a solution that allows to use a stack lock file / cabal freeze file for individual packages that are difficult to build with modern Haskell libraries, but it wouldn’t be a sustainable large scale solution in my estimate.

@amjoseph

the “nix way”

I fail to see how just wrapping whatever cargo does in a derivation (using cargo vendor and cargo build) is the Nix way to be honest. In fact, in this approach the derivation abstraction provided by Nix is arguably under-utilized.

@amjoseph

I’ve encountered a disheartening level of breakage in haskellPackages which seems inconsistent with the extremely high level of quality throughout the rest of nixpkgs.

I’d be curious what exactly the “disheartening level of breakage” you describe is. The quality is lower than the rest of nixpkgs sure, since derivations are added automatically via code generation of which some can’t be expected to work (and are marked as broken). Such derivations would of course never be added if they were maintained manually, as the rest of nixpkgs is.

From my perspective (one of the Haskell maintainers, that is) the situation is as follows: We have 4 core Haskell maintainers and I guess ~20 other occasional contributors, all of them volunteers. Together we maintain a consistent (“blessed”) Haskell package set that has over 6000 packages working, tested over 3 platforms (aarch64-linux, x86_64-darwin and x86_64-linux) and working to a high degree on a fourth (aarch64-darwin). We were able to go as far as over 7000 before recent ecosystem changes. Hackage provides 16000 packages in total (many if not most of them we probably can’t hope to get to work), less than half of our working packages are part of Stackage LTS. I would conclude: Not bad, considering that we can’t do arbitrary version constraint solving.

Of course, we necessarily are a kind of opinionated Haskell distribution (much like Stackage), so if you are trying to get a differing approach to work with it, the experience won’t be great. Then again, the primary objective has always been packaging Haskell software for NixOS / the nixpkgs software distribution which has generally worked well so far.

Sorry for going on this huge tangent, I realize the thread is actually about something else. As for marking things broken, a big problem relating to Haskell I’ve observed is that it is often hard to tell what in a NixOS configuration caused a broken eval failure without the use of --show-trace. We caused this situation accidentally by improving the accuracy of the broken report and reducing the amount of packages that were marked as broken by accident. Not sure how exactly this could be improved, I think ideally we could add more tracing abilities to the module system.