Ricardo Wurmus <rek...@elephly.net> writes: >> Based on your earlier suggestion, I played around with removing all the >> packages that GHC provides. I made the same change to ghc-mtl on >> core-updates, and it allows me to build ghc-resourcet. > […] >> Is this too drastic? I could rebase on top of your ghc-mtl changes and >> submit a patch if you think its OK. > > Not too drastic. This is exactly what I had hoped for :) > > Thank you for making the effort. A patch on top of latest core-updates > / master would be very welcome.
I sent the patch. It’s bug #30501. (The most complicated part was the changelog; I hope it’s OK!) > Now, how do we prevent this in the future? Can we modify “guix lint” to > warn about these cases? Can we also change the hackage importer to > keep these packages out of the inputs of generated package definitions? I can think of two approaches. We could follow the style of Hackage and force everything to reference the base libraries. To make this work, we would have to make builds fail if they don’t reference a base library that they need. Maybe there’s a way to hide the base libraries in the Haskell build system, and use packages to expose them. The major downside to this is adding a “ghc-base” input to every Haskell package (and “ghc-binary” to a bunch, etc.). The upside is that it is more intuitive: the inputs look more like Hackage, and you could try new versions of the base libraries using standard Guix tools like: $ guix package -i ghc-pandoc \ --with-input=ghc-transformers=ghc-transformers-new (This would update all the dependencies, too, leaving the GHC-provided library hidden and only exposing the new library, thus avoiding all the conflicting version problems.) We would have to make sure that “guix package -i ghc” still provides the libraries, though, to save people a lot of confusion. The second approach would be to leave everything implicit, and add notes everywhere not to break things (in the docs, the linter, and the importer). I guess we would have to be careful when updating GHC in case it adopts new base libraries. The appeal of this approach is that it is basically what we just did, so it’s done modulo the changes to the linter and importer. Personally, I prefer the first approach even though it’s a bit of a radical departure. It feels like it fits more both with Guix and Haskell. I also think that most Haskell people coming to Guix would just understand it without any extra explanation. Updating every single Haskell package is a bit daunting :S. It’s something I’m willing to look at, though. What do you think? I’m happy to look at the linter and importer, too. I would like to package “git-annex”, so making the Haskell stuff a little nicer is only a minor detour towards that goal (last I checked, I will have to import a lot of packages yet). -- Tim