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

Stop using system-ghc silently…or at all. #2221

Closed
bitemyapp opened this Issue May 31, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@bitemyapp
Contributor

bitemyapp commented May 31, 2016

screen shot 2016-05-31 at 3 54 34 pm

This happens a fair bit, and not just in connection with ghc-mod although it's the most common culprit. While doing the training at LambdaConf we had a beginner get very confused because their system installed GHC was pre-FTP and the Stack provided GHC was 7.10.3. From there, they didn't understand ghci and stack ghci would be from substantially different versions of GHC.

I'd really like Stack to stop implicitly using system-installed versions of GHC without explicit direction from the user.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jun 1, 2016

Agreed, I'm tired of asking whether or not the user is using a custom ghc install.

This inspired me to consider another source of reproduction difficulty is whether stack was built via stack or cabal - I've opened this ticket on that.

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 16, 2016

For context, @mgsloan's comment from #1901:

Some discussions of why the system ghc is preferred:

I'm not sure if I buy it, I'm leaning towards making "system ghc" usage opt-in, but this would be a breaking change...

@bitemyapp

This comment has been minimized.

Contributor

bitemyapp commented Jul 16, 2016

I got bit by system-ghc being the default last week when I tried to switch to profiling libraries. Remembered I might accidentally be using system-ghc which was causing the dependency failures. Lost a half hour or more to that and I know Stack pretty well. Imagine it'd be a hard stop for a new person trying to profile their project.

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 17, 2016

Ok, so I'm totally in favor of switching to --no-system-ghc by default in one of the next few releases.

I don't have a good idea of the breakage that could result from changing the default behaviour, and currently use stack-provided compilers exclusively, so I'd like to do the switch with sufficient time before a release, so it can be beta-tested thoroughly.

This means that the switch can only happen once the store version-hash issue (#2296) has been resolved because I'd feel really bad about all the beta-testers wasting their time while their extra-deps compile…

@mgsloan: Any idea when #2296 might be resolved?

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 22, 2016

This FAQ entry will need to be edited once the switch is done:

https://docs.haskellstack.org/en/stable/faq/#i-already-have-ghc-installed-can-i-still-use-stack

@shanemikel

This comment has been minimized.

shanemikel commented Jul 29, 2016

First attempt at profiling Haskell today. I've been digging around for hours now, and I've finally got something to compile (with --no-system-ghc). Until this is fixed, would somebody mind adding a note to the docs section on profiling?

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Aug 9, 2016

First attempt at profiling Haskell today. I've been digging around for hours now, and I've finally got something to compile (with --no-system-ghc).

@shanemikel: What were the symptoms of using the wrong GHC? Feel free to make a PR (targeting the stable branch) for that note!

@bitemyapp

This comment has been minimized.

Contributor

bitemyapp commented Aug 29, 2016

Just to add to this, I just got bitten by profiling <> system-ghc again

sjakobi added a commit that referenced this issue Sep 28, 2016

Default to using a stack-installed, isolated GHC #2221
Address option compatibility issues around the new default setting:

* Add notes to ghc-variant and setup --reinstall help texts
* Add a check to catch uses of ghc-variant in combination with
  no-system-ghc

sjakobi added a commit that referenced this issue Oct 9, 2016

Default to using a stack-installed, isolated GHC #2221
Address option compatibility issues around the new default setting:

* Add notes to ghc-variant and setup --reinstall help texts
* Add a check to catch uses of ghc-variant in combination with
  no-system-ghc

sjakobi added a commit that referenced this issue Oct 13, 2016

Default to using a stack-installed, isolated GHC #2221
Address option compatibility issues around the new default setting:

* Add notes to ghc-variant and setup --reinstall help texts
* Add a check to catch uses of ghc-variant in combination with
  no-system-ghc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment