From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: heads-up: Haskell updates Date: Sun, 18 Feb 2018 00:22:32 +0100 Message-ID: <87k1vb5hhj.fsf@elephly.net> References: <87r2ppjbst.fsf@elephly.net> <873723pfya.fsf@netris.org> <871shn8jm5.fsf@elephly.net> <87zi4b744f.fsf@elephly.net> <20180214234721.4e9fe198@scratchpost.org> <87a7waodaa.fsf@netris.org> <20180215120404.0a96b628@scratchpost.org> <87fu626yvj.fsf@elephly.net> <20180215180340.52db6ded@scratchpost.org> <20180216162642.106e9c7c@scratchpost.org> <87po54vqug.fsf@fastmail.com> <87y3js6da0.fsf@elephly.net> <87o9knvmra.fsf@gmail.com> <87tvuf6c8s.fsf@elephly.net> <87fu5zvkqc.fsf@gmail.com> <87r2pj6a9j.fsf@elephly.net> <87371zg2ij.fsf@ngyro.com> <87o9kn65l3.fsf@elephly.net> <87po53mwkm.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enBov-0000pM-M2 for guix-devel@gnu.org; Sat, 17 Feb 2018 18:23:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enBos-0000AG-IP for guix-devel@gnu.org; Sat, 17 Feb 2018 18:23:05 -0500 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21117) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1enBos-00009s-BD for guix-devel@gnu.org; Sat, 17 Feb 2018 18:23:02 -0500 In-reply-to: <87po53mwkm.fsf@ngyro.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Timothy Sample Cc: guix-devel 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=E2=80=99t reference a base library that they need. Mayb= e > there=E2=80=99s a way to hide the base libraries in the Haskell build sys= tem, > and use packages to expose them. The major downside to this is adding a > =E2=80=9Cghc-base=E2=80=9D input to every Haskell package (and =E2=80=9Cg= hc-binary=E2=80=9D 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=3Dghc-transformers=3Dghc-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=E2=80=99t 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=E2=80=99ve tried building many packages with n= ewer versions of e.g. transformers and it rarely worked without problems. If there=E2=80=99s only one package where we have to use an older version o= f 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=E2=80=99s 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=E2=80=99t= 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). --=20 Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net