diff mbox series

[bug#67896] gnu: ghc-9.2: Make Cabal respect GHC_PACKAGE_PATH

Message ID 6fccf7c2e9095cb27cb93644f3bd4a92f4687d13.1702980332.git.soeren@soeren-tempel.net
State New
Headers show
Series [bug#67896] gnu: ghc-9.2: Make Cabal respect GHC_PACKAGE_PATH | expand

Commit Message

Sören Tempel Dec. 19, 2023, 10:05 a.m. UTC 
From: Sören Tempel <soeren@soeren-tempel.net>

**tl;dr** Applying this patch makes Cabal work in Guix environments
and ensures that Cabal picks up Haskell packages installed via Guix.

Guix makes heavy use of GHC_PACKAGE_PATH to make GHC pickup Haskell
packages installed via the Guix package manager. The environment
variable is set using native-search-paths from the GHC packages.

Unfortunately, upstream Cabal does presently not respect
GHC_PACKAGE_PATH. If this environment variable is set, `cabal build`
and other commands will terminate. For building packages, Guix does
not make much use of cabal-install hence this is not as big of an
issue. However, cabal-install does therefore presently not work
out-of-the-box in environments created by Guix. For example,
in `guix shell` environments. This makes it essentially impossible
to use Guix for setting up development environments for Haskell software.

Cabal upstream is aware of this issue and a patch exists to workaround
this problem. The patch is currently not merged upstream due to issues
related to reconfiguration (changing GHC_PACKAGE_PATH between `cabal
configure` and `cabal build`). However, I would argue that this edge
case is not that relevant for Guix and therefore propose including
this patch with the Cabal Guix package. As outlined above, cabal-install
is not usable by default presently, and I would therefore argue that
this is a major improvement over the current situation. I am willing to
work with Cabal upstream to have this issue fixed upstream eventually.

Note that this requires patching the GHC package instead of the
cabal-install package as Guix uses the version of the Cabal package
<https://hackage.haskell.org/package/Cabal> distributed with GHC.

See: https://github.com/haskell/cabal/issues/3728

* gnu/packages/haskell-apps.scm (cabal-install): Include patch
to support the GHC_PACKAGE_PATH environment variable.

Signed-off-by: Sören Tempel <soeren@soeren-tempel.net>
---
 gnu/packages/haskell.scm                      |  3 +-
 .../ghc-9.2-cabal-support-package-path.patch  | 67 +++++++++++++++++++
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/ghc-9.2-cabal-support-package-path.patch


base-commit: 29c94dd522833b2603a651c14a5b06120bcf1829

Comments

Sören Tempel Jan. 6, 2024, 9:09 a.m. UTC | #1 
If we don't want to patch the vendored Cabal version shipped by GHC
itself, we could also explore packaging Cabal separately and making
cabal-install depend on that. However, given that Setup.hs also uses
Distribution.Simple and that there are several places in Guix itself
where we need to unset GHC_PACKAGE_PATH atm, I personally believe it
to be preferable to fix the vendored version.

Lars, what do you think?

Greetings
Sören
Lars-Dominik Braun Jan. 6, 2024, 2:49 p.m. UTC | #2 
Hi,

sorry for the delay, I just tried your patch and it works well combining
a local cabal project and libraries/GHC from Guix. I’d say this is a
massive improvement, so I’d like to ship it with Guix. However this
is a world rebuilding change, so I’ll push it to the haskell-team
branch and probably wait for #67921 to be ready before it can hit master.

One minor issue: If you add a patch file, also add it to gnu/local.mk.

> However, given that Setup.hs also uses
> Distribution.Simple and that there are several places in Guix itself
> where we need to unset GHC_PACKAGE_PATH atm, I personally believe it
> to be preferable to fix the vendored version.

Which locations are you referring to?

Cheers,
Lars
Sören Tempel Jan. 6, 2024, 3:07 p.m. UTC | #3 
Hi,

Lars-Dominik Braun <lars@6xq.net> wrote:
> sorry for the delay, I just tried your patch and it works well combining
> a local cabal project and libraries/GHC from Guix. I’d say this is a
> massive improvement, so I’d like to ship it with Guix. However this
> is a world rebuilding change, so I’ll push it to the haskell-team
> branch and probably wait for #67921 to be ready before it can hit master.

Yea, glad to hear that. Waiting for #67921 is fine by me. Should I also
prepare a patch for the GHC 9.4 package then? Currently this is only GHC
9.2.

> One minor issue: If you add a patch file, also add it to gnu/local.mk.

Oh, I wasn't aware. Thanks for pointing that out, will keep it in mind
for future patches!

> > However, given that Setup.hs also uses
> > Distribution.Simple and that there are several places in Guix itself
> > where we need to unset GHC_PACKAGE_PATH atm, I personally believe it
> > to be preferable to fix the vendored version.
> 
> Which locations are you referring to?

I just grep'ed for GHC_PACKAGE_PATH, e.g.:

* https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/virtualization.scm#n784
* https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/haskell-build-system.scm#n111
* https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell.scm#n963

Greetings
Sören
Lars-Dominik Braun Jan. 6, 2024, 3:51 p.m. UTC | #4 
Hi,

> Yea, glad to hear that. Waiting for #67921 is fine by me. Should I also
> prepare a patch for the GHC 9.4 package then? Currently this is only GHC
> 9.2.

as far as I see 9.4 inherits from 9.2 and thus this patch should be
applied automatically.

> I just grep'ed for GHC_PACKAGE_PATH, e.g.:
> 
> * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/virtualization.scm#n784
> * https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/haskell-build-system.scm#n111
> * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell.scm#n963

Ah, I see. I’ll check whether this is still necessary.

Cheers,
Lars
Saku Laesvuori Jan. 6, 2024, 9:16 p.m. UTC | #5 
> Hi,
> 
> Lars-Dominik Braun <lars@6xq.net> wrote:
> > sorry for the delay, I just tried your patch and it works well combining
> > a local cabal project and libraries/GHC from Guix. I’d say this is a
> > massive improvement, so I’d like to ship it with Guix. However this
> > is a world rebuilding change, so I’ll push it to the haskell-team
> > branch and probably wait for #67921 to be ready before it can hit master.
> 
> Yea, glad to hear that. Waiting for #67921 is fine by me. Should I also
> prepare a patch for the GHC 9.4 package then? Currently this is only GHC
> 9.2.

I'm currently trying to update GHC to 9.6 in that series (there are some
weird issues when running the test suite). If the same cabal patch works
with GHC 9.6 I can add the reference to it in the package definition
(same with 9.4). Otherwise a patch for those versions would be nice.
Sören Tempel Jan. 7, 2024, 9:37 a.m. UTC | #6 
I just tested this, the patch applies cleanly for both GHC 9.4.8 and 9.6.3.

Saku Laesvuori <saku@laesvuori.fi> wrote:
> > Hi,
> > 
> > Lars-Dominik Braun <lars@6xq.net> wrote:
> > > sorry for the delay, I just tried your patch and it works well combining
> > > a local cabal project and libraries/GHC from Guix. I’d say this is a
> > > massive improvement, so I’d like to ship it with Guix. However this
> > > is a world rebuilding change, so I’ll push it to the haskell-team
> > > branch and probably wait for #67921 to be ready before it can hit master.
> > 
> > Yea, glad to hear that. Waiting for #67921 is fine by me. Should I also
> > prepare a patch for the GHC 9.4 package then? Currently this is only GHC
> > 9.2.
> 
> I'm currently trying to update GHC to 9.6 in that series (there are some
> weird issues when running the test suite). If the same cabal patch works
> with GHC 9.6 I can add the reference to it in the package definition
> (same with 9.4). Otherwise a patch for those versions would be nice.
diff mbox series

Patch

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 62815efbb1..0cd0734d6d 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -1348,7 +1348,8 @@  (define-public ghc-9.2
                 (sha256
                  (base32
                   "07028i0hm74svvq9b3jpkczaj6lsdgn3hgr4wa7diqiq3dypj1h6"))
-                (patches (search-patches "ghc-9.2-glibc-2.33-link-order.patch"))))
+                (patches (search-patches "ghc-9.2-glibc-2.33-link-order.patch"
+                                         "ghc-9.2-cabal-support-package-path.patch"))))
       (arguments
        (substitute-keyword-arguments (package-arguments base)
          ((#:phases phases '%standard-phases)
diff --git a/gnu/packages/patches/ghc-9.2-cabal-support-package-path.patch b/gnu/packages/patches/ghc-9.2-cabal-support-package-path.patch
new file mode 100644
index 0000000000..9e4c405c50
--- /dev/null
+++ b/gnu/packages/patches/ghc-9.2-cabal-support-package-path.patch
@@ -0,0 +1,67 @@ 
+Without this patch, Cabal terminates if GHC_PACKAGE_PATH is set. This is
+an annoyance with Guix as it makes heavy use of GHC_PACKAGE_PATH to have
+GHC pickup Haskell package installed via Guix. Therefore, Cabal does
+presently not work by default in environments created by Guix. This is
+a workaround which makes Cabal respect GHC_PACKAGE_PATH.
+
+Taken from https://github.com/haskell/cabal/issues/3728
+
+diff -upr a/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs b/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs
+--- a/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs	2022-11-06 20:41:17.000000000 +0100
++++ b/libraries/Cabal/Cabal/src/Distribution/Simple/GHC.hs	2023-12-18 14:34:15.148911717 +0100
+@@ -71,6 +71,7 @@ module Distribution.Simple.GHC (
+  ) where
+ 
+ import Prelude ()
++import Distribution.Compat.Environment (lookupEnv)
+ import Distribution.Compat.Prelude
+ 
+ import qualified Distribution.Simple.GHC.Internal as Internal
+@@ -117,7 +118,7 @@ import System.Directory
+          , canonicalizePath, removeFile, renameFile, getDirectoryContents )
+ import System.FilePath          ( (</>), (<.>), takeExtension
+                                 , takeDirectory, replaceExtension
+-                                ,isRelative )
++                                , isRelative, searchPathSeparator )
+ import qualified System.Info
+ #ifndef mingw32_HOST_OS
+ import System.Posix (createSymbolicLink)
+@@ -333,9 +334,11 @@ getInstalledPackages :: Verbosity -> Com
+                      -> ProgramDb
+                      -> IO InstalledPackageIndex
+ getInstalledPackages verbosity comp packagedbs progdb = do
+-  checkPackageDbEnvVar verbosity
+   checkPackageDbStack verbosity comp packagedbs
+-  pkgss <- getInstalledPackages' verbosity packagedbs progdb
++  envPackageDBs <-
++    maybe [] (map SpecificPackageDB . unintersperse searchPathSeparator)
++      <$> lookupEnv "GHC_PACKAGE_PATH"
++  pkgss <- getInstalledPackages' verbosity (envPackageDBs ++ packagedbs) progdb
+   index <- toPackageIndex verbosity pkgss progdb
+   return $! hackRtsPackage index
+ 
+@@ -405,10 +408,6 @@ getUserPackageDB _verbosity ghcProg plat
+     packageConfFileName = "package.conf.d"
+     ghcVersion = fromMaybe (error "GHC.getUserPackageDB: no ghc version") $ programVersion ghcProg
+ 
+-checkPackageDbEnvVar :: Verbosity -> IO ()
+-checkPackageDbEnvVar verbosity =
+-    Internal.checkPackageDbEnvVar verbosity "GHC" "GHC_PACKAGE_PATH"
+-
+ checkPackageDbStack :: Verbosity -> Compiler -> PackageDBStack -> IO ()
+ checkPackageDbStack verbosity comp =
+     if flagPackageConf implInfo
+@@ -461,8 +460,11 @@ getInstalledPackagesMonitorFiles :: Verb
+                                  -> ProgramDb
+                                  -> [PackageDB]
+                                  -> IO [FilePath]
+-getInstalledPackagesMonitorFiles verbosity platform progdb =
+-    traverse getPackageDBPath
++getInstalledPackagesMonitorFiles verbosity platform progdb packageDBs = do
++    envPackageDBs <-
++      maybe [] (map SpecificPackageDB . unintersperse searchPathSeparator)
++        <$> lookupEnv "GHC_PACKAGE_PATH"
++    traverse getPackageDBPath (envPackageDBs ++ packageDBs)
+   where
+     getPackageDBPath :: PackageDB -> IO FilePath
+     getPackageDBPath GlobalPackageDB =