Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack ghci ignores flags in stack.yaml and uses package.cabal defaults #5434

Closed
liskin opened this issue Nov 15, 2020 · 2 comments
Closed

stack ghci ignores flags in stack.yaml and uses package.cabal defaults #5434

liskin opened this issue Nov 15, 2020 · 2 comments

Comments

@liskin
Copy link
Contributor

liskin commented Nov 15, 2020

Steps to reproduce

Minimal example:

#!/usr/bin/env bash

set -ex

mkdir /tmp/stack-ghci-flags-bug
cd /tmp/stack-ghci-flags-bug

wget https://github.com/commercialhaskell/stack/releases/download/v2.5.1/stack-2.5.1-linux-x86_64.tar.gz
tar xaf stack-2.5.1-linux-x86_64.tar.gz

mkdir -p bug/src

cat >bug/bug.cabal <<END
name:               bug
version:            0.1
cabal-version:      >= 1.10
build-type:         Simple

flag someflag
    default: False

library
    default-language: Haskell2010
    hs-source-dirs:  src

    build-depends: base
    exposed-modules: Bug1

    if flag(someflag)
        build-depends: containers
        other-modules: Bug2
        cpp-options: -DBUG
END

cat >bug/src/Bug1.hs <<END
{-# LANGUAGE CPP #-}
module Bug1 (Maybe) where
import Data.Maybe
#ifdef BUG
import Bug2
#endif
END

cat >bug/src/Bug2.hs <<END
module Bug2 (Map) where import Data.Map
END

cat >stack.yaml <<END
resolver: lts-16.18
packages:
    - bug
flags:
    bug:
        someflag: true
END

./stack-2.5.1-linux-x86_64/stack --stack-root "$PWD"/.stack --system-ghc build
./stack-2.5.1-linux-x86_64/stack --stack-root "$PWD"/.stack --system-ghc ghci bug:lib

This results in

Configuring GHCi with the following packages: bug
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/tomi/.ghc/ghci.conf
[1 of 2] Compiling Bug1             ( /tmp/stack-ghci-flags-bug/bug/src/Bug1.hs, interpreted )
[2 of 2] Compiling Bug2             ( /tmp/stack-ghci-flags-bug/bug/src/Bug2.hs, interpreted )

/tmp/stack-ghci-flags-bug/bug/src/Bug2.hs:1:25: error:
    Could not load module ‘Data.Map’
    It is a member of the hidden package ‘containers-0.6.2.1’.
    You can run ‘:set -package containers’ to expose it.
    (Note: this unloads all the modules in the current scope.)
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
1 | module Bug2 (Map) where import Data.Map
  |                         ^^^^^^^^^^^^^^^
Failed, one module loaded.

<no location info>: error:
    Could not load module ‘Bug2’
    it is a hidden module in the package ‘bug-0.1’
Loaded GHCi configuration from /tmp/haskell-stack-ghci/3889aa92/ghci-script

With ./stack-2.5.1-linux-x86_64/stack --stack-root "$PWD"/.stack --system-ghc ghci --flag bug:someflag bug:lib it works just fine.

Adding -v reveals that -DBUG isn't passed to ghci either. Do note that my expected behaviour is not that Bug2 wouldn't be loaded. My expected behaviour is that the ghci is invoked with -DBUG and -package-id=containers-…, so that I can use ghci and ghcid with the flags that I set in stack.yaml.

Now here's a non-minimal real life example, just to show that this is actually reproducible with a real project, that perhaps some of you folks use and love:

#!/usr/bin/env bash

set -ex

mkdir /tmp/stack-ghci-flags-bug-xmobar
cd /tmp/stack-ghci-flags-bug-xmobar

wget https://github.com/commercialhaskell/stack/releases/download/v2.5.1/stack-2.5.1-linux-x86_64.tar.gz
tar xaf stack-2.5.1-linux-x86_64.tar.gz

git clone https://github.com/jaor/xmobar

cat >stack.yaml <<END
resolver: lts-16.18
packages:
    - xmobar
flags:
    xmobar:
        with_xft: true
END

./stack-2.5.1-linux-x86_64/stack --stack-root "$PWD"/.stack --system-ghc build
./stack-2.5.1-linux-x86_64/stack --stack-root "$PWD"/.stack --system-ghc ghci xmobar:lib

This fails with:

[58 of 67] Compiling Xmobar.X11.MinXft ( /tmp/stack1/xmobar/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/build/Xmobar/X11/MinXft.hs, interpreted )

src/Xmobar/X11/MinXft.hsc:49:1: error:
    Could not load module ‘Graphics.X11.Xrender’
    It is a member of the hidden package ‘X11-xft-0.3.1’.
    You can run ‘:set -package X11-xft’ to expose it.
    (Note: this unloads all the modules in the current scope.)
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
Failed, 57 modules loaded.

<no location info>: error:
    Could not load module ‘Xmobar’
    It is a member of the hidden package ‘xmobar-0.37’.
    You can run ‘:set -package xmobar’ to expose it.
    (Note: this unloads all the modules in the current scope.)

Stack version

$ ./stack-2.5.1-linux-x86_64/stack --version
Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0

It's also reproducible with stack 2.3.3 from Debian.

Method of installation

wget https://github.com/commercialhaskell/stack/releases/download/v2.5.1/stack-2.5.1-linux-x86_64.tar.gz
tar xaf stack-2.5.1-linux-x86_64.tar.gz

The rest of the system is Debian testing on amd64 with ghc 8.8.4.

liskin added a commit to liskin/dotfiles that referenced this issue Nov 15, 2020
This triggers a bug in stack
(commercialhaskell/stack#5434) whenever I run
ghcid, drop it for now.

This reverts commit c4a8d86.
@jneira
Copy link
Contributor

jneira commented Nov 15, 2020

@liskin many thanks for open a different issue, with so many details.

@mattaudesse
Copy link
Member

Thanks for the excellent write-up @liskin 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants