yushyin
commented
4 years ago I have the same problem. It prevents me from using ghcide with stack, because mixins don't work.
Open chshersh opened 5 years ago
yushyin
commented
4 years ago I have the same problem. It prevents me from using ghcide with stack, because mixins don't work.
Kleidukos
commented
4 years ago Hi! I have the exact same problem with this project. @snoyberg do you have any idea what it could be?
gribouille
commented
4 years ago Same problem for me. cababl new-repl works!
nuttycom
commented
4 years ago I have the same issue. It's a blocker for me using stack on my projects.
jneira
commented
4 years ago I had to change my cleaner mixins stanza for PackageImports + CPP due to this, too
sjakobi
commented
4 years ago I have a bit of time to spend on this issue. Unfortunately I'm neither very familiar with mixins nor with the relevant code in stack.
So far I've created a fairly minimal reproducer for this issue: https://github.com/sjakobi/stack-repl-mixin#readme
What I understand from looking at the way cabal repl invokes ghci, is that the mixin info should be passed in with the -package-id option:
For a package that has
mixins: base hiding (Prelude)
, relude (Relude as Prelude), the invocation looks like this:
ghc --interactive ... -package-id 'base-4.13.0.0 (Control.Applicative, ..., Unsafe.Coerce)' -package-id 'relude-0.7.0.0-a762b0db97a8db7c442717031b276b7c996c29e935fa7b59555e477a6a1a6d3a (Relude as Prelude)'Notably, the list of base modules excludes Prelude.
On the Cabal side, the mixin info is provided via BuildInfo's mixins field.
In stack, the -package-id options are contained in the bioPackageFlags via the ghciPkgOpts that are generated here:
So the next step for me would be to figure out how to get the mixins info from Cabal's BuildInfo into the bioPackageFlags.
@snoyberg, @qrilka, does this sound like a reasonable plan of attack? Do you have any advice or pointers for me?
@ezyang, do you have any comments or advice? Does my idea to naively enhance stack's GhciPkgInfo with the mixins info from Cabal's BuildInfo seem likely to work or am I possibly missing some fundamental complication? I was surprised that grepping for mixin in the cabal-install source didn't result in any hits. It appears that cabal-install somehow gets away with any mixins logic being handled in Cabal. I wonder whether there's a more elegant solution for this issue that could similarly rely on Cabal's mixins handling.
My work is on this branch: https://github.com/commercialhaskell/stack/compare/master...sjakobi:sjakobi/5077-repl-mixins
snoyberg
commented
4 years ago I don’t have much to add, but that overall seems like a reasonable approach.
ezyang
commented
4 years ago I need to check if BuildInfo is after Backpack has done mixin linking or not. Naively my expectation is that it will be "easy" to add support for use of mixins that is internal to a library only, and "hard" to add it for mixins that refer to external libraries.
sjakobi
commented
4 years ago I'd like to continue working on this issue soon.
I need to check if BuildInfo is after Backpack has done mixin linking or not.
@ezyang Do you have a pointer for how I could figure this out myself?
I guess https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/backpack-2016.pdf would be good background reading?!
ezyang
commented
4 years ago @sjakobi OK, I checked, BuildInfo is before mixin linking has happened (it's parsed directly from the Cabal file). However, if there isn't any Backpack involved, then this suggestion:
Does my idea to naively enhance stack's GhciPkgInfo with the mixins info from Cabal's BuildInfo seem likely to work or am I possibly missing some fundamental complication?
Will give you an incorrect but still useful version that will do the right thing for people who aren't actually using Backpack signatures. At least for the original reporter of this bug, their problem will be solved.
If you're interested in full on Backpack, I'd actually probably recommend my thesis for background reading https://github.com/ezyang/thesis/releases
ulidtko
commented
7 months ago Bump. Still an issue.
Apart from Ambiguous module name ‘Prelude’: it was found in multiple packages that this issue causes — there's also GHC bug #10920 that will become a blocking issue afterwards, attempting to use module ‘Prelude’ which is not loaded.
@sjakobi you've apparently gotten a green light to fix this, any success or further findings? I've checked your branch, but there isn't much there.
eeoam
commented
2 months ago Hello - today I tried to use mixins with stack repl and it didn't work so it appears that this is still an open issue (after almost half a decade!). @sjakobi any chance this will be fixed in the near future?
General summary/comments (optional)
I have a project that follows the
mixinsapproach of using an alternative prelude. When trying to load the project in GHCi viastack repl, I see multiple defintions not in scope errors. I tried to create a minimal example, but I couldn't.stackworks on my small examples even with common stanzas, multiple stanzas, but for some reasons doesn't work on the following packages (however, the build is successful):Steps to reproduce
git clone git@github.com:kowainik/summoner.gitcd summonerstack repl summonerExpected
Successfully entering REPL without compilation errors.
Actual
What actually happened.
If you suspect that a stack command misbehaved, please include the output of that command in
--verbosemode. If the output is larger than a page please paste the output in a Gist.Stack version
Method of installation