Hi Timothy, > 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.)
This wouldn’t be good, because we would have to make sure that the base packages are kept at the versions of the packages that are provided by GHC itself. Newer versions for these base packages are often different enough to cause problems. I’ve tried building many packages with newer versions of e.g. transformers and it rarely worked without problems. If there’s only one package where we have to use an older version of one of the base packages we would introduce problems when that package were to be used with other packages. We must avoid this. > 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. I much prefer this. FWIW we already do this for R packages. We just have to accept that GHC provides some modules that are also available as separate packages. Leaving these packages off when writing package definitions is the only solution that ensures that we won’t run into conflicts at some later point. When we update the default GHC we will have to read the migration notes anyway (these notes tell us what modules are now part of GHC or have been spun out as separate packages). -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
