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

Support GHC 8 #716

Merged
merged 55 commits into from Jun 4, 2017

Conversation

Projects
None yet
6 participants
@hyiltiz

hyiltiz commented Mar 30, 2017

Solves #690 .

abarbu and others added some commits Apr 4, 2017

Merge pull request #8 from vaibhavsagar/bump-lts-8.8
Bump resolvers to lts-8.8
Remove shelly-1.6.8.3 from extra-deps
It is included in the current resolver
Merge pull request #10 from vaibhavsagar/remove-extra-dep
Remove shelly-1.6.8.3 from extra-deps
Merge pull request #11 from vaibhavsagar/bump-resolver
Bump resolvers to lts-8.12
@ccressent

This comment has been minimized.

ccressent commented May 10, 2017

@hyiltiz
@vaibhavsagar

What's the plan regarding ghc support? Which versions should we aim to support? @abarbu said he only cares about ghc 8. Would supporting both 7.10 and 8 make sense?

I had started to fix the CI and update to ghc 8 in my own fork but it's clearly duplicating work done in this PR...

@gibiansky: are there commits we can salvage off your 1.0 branch? I've seen your message on the Haskell mailing list and I'm willing to help!

@vaibhavsagar

This comment has been minimized.

Collaborator

vaibhavsagar commented May 10, 2017

Good question! I think it might actually be easier to take the fork and try to make it compile under GHC 7.10 than the other way round 😄. The big change between 7.10 and 8 IMHO is the change from bin-package-db to ghc-boot for looking at system packages, and I think that code is mostly untouched so it should be possible to support both. I'm also curious about changes we can take from the 1.0 branch, it looked like a fairly ambitious refactoring.

@gibiansky

This comment has been minimized.

Owner

gibiansky commented May 10, 2017

It was, indeed, a fairly ambitious refactoring that never got completed. However, the goal of it was actually to drop GHC 7 support entirely, and have future versions support only GHC 8. So I don't mind that happening, actually, as long as there is a clear tag for the last version to support GHC 7 and info on the readme about that.

I don't mind having a fork around if that seems to be the best solution, but if someone is interested in avoiding a fork (which I think is OK but a bit confusing for users), and wants to put in the effort to merge the changes that make GHC 8 work (meanwhile removing support for GHC 7, if they so desire), I am happy to look at a PR and grant them commit access.

@abarbu

This comment has been minimized.

Contributor

abarbu commented May 10, 2017

I agree that it's confusing to have a fork for GHC 8. Also, I don't want to maintain the fork, I just need ihaskell so I'm doing it :)

I think that backward-compatibility is a noble goal but is it the best use of the limited resources of this project? There are lots of other changes that would be more helpful for the vast majority of users.

Don't underestimate the huge amounts of extra overhead backward compatibility adds in terms of support, code, complexity, knowledge required to make changes, the inability to take advantage of new features easily, the complexity of the build system and the interpreter, the complexity of the instructions to build and use ihaskell, etc. This will only get worse with time (with say.. backpack which users will want support for).

The older version of ihaskell will always live on in stack.

It's also not as easy as just targeting GHC 7, it means being compatible with old versions of every widget/display library that might have broken support for GHC 7. Also, folks that run older versions of GHC will probably also want to run older versions of ipython. jupyter has changed quite a bit, even the data model of widgets has (my branch only does enough to make things just about work but it breaks old versions in the process). Backward compatibility there is going to be another significant resource drain and isn't easy.

@gibiansky

This comment has been minimized.

Owner

gibiansky commented May 10, 2017

@abarbu We're on the same page, I think, right?

I'm happy to drop support for GHC 7, as long as we just make a tag on Github for the last version that did support it and put a note in the README about that.

@abarbu

This comment has been minimized.

Contributor

abarbu commented May 10, 2017

@gibiansky Yup! I just wanted to warn away anyone that thinks backward compatibility isn't a big deal.

@ccressent

This comment has been minimized.

ccressent commented May 11, 2017

@abarbu raises a good point regarding limited resources and it looks like the consensus is to go with ghc 8 support only. That's perfectly fine and reasonable to me!

This PR is getting fairly large, I suggest the following course of action:

  1. Finish the ghc 8 work and get this PR merged in
  2. Fix and optimize the CI
  3. Then we can work on open issues

@abarbu, @vaibhavsagar: what can I do to help with 1. and 2.?

@vaibhavsagar

This comment has been minimized.

Collaborator

vaibhavsagar commented May 11, 2017

I don't think anything further needs to be added to this PR. We should be able to merge it in as is and go from there.

@gibiansky

This comment has been minimized.

Owner

gibiansky commented May 27, 2017

OK, in the interest of having something happen – @abarbu, I am happy to grant you commit access if you are willing to make a GHC 7 tag based on current master, merge the PR, and update the docs to reflect that IHaskell now only supports GHC 8. Do you have the time / desire to make that happen?

@vaibhavsagar

This comment has been minimized.

Collaborator

vaibhavsagar commented May 27, 2017

I'm more than happy to do this if @abarbu is not available!

@abarbu

This comment has been minimized.

Contributor

abarbu commented May 30, 2017

Sure. I'm happy to make it happen when I get a chance in the next day or two if you give me access.

@gibiansky

This comment has been minimized.

Owner

gibiansky commented Jun 3, 2017

@abarbu @vaibhavsagar You are both now listed as collaborators, and should be able to push to the repo and merge PRs. Please use this power wisely, and I appreciate your help with making this PR happen :)

@vaibhavsagar

This comment has been minimized.

Collaborator

vaibhavsagar commented Jun 4, 2017

I've created a tag and am about to merge this PR.

@vaibhavsagar vaibhavsagar merged commit 19ba3cd into gibiansky:master Jun 4, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@vaibhavsagar

This comment has been minimized.

Collaborator

vaibhavsagar commented Jun 4, 2017

I've updated the docs to reflect that only GHC 8 is supported.

@leftaroundabout

This comment has been minimized.

Contributor

leftaroundabout commented Sep 6, 2017

@abarbu I agree that we shouldn't waste much time on backwards compatibility, but as of now I don't see your fears confirmed: the HEAD version if IHaskell is easy to get running with GHC-7.10, as per #747. Whilst this is so simple, I think we should keep that compatibility.

When we do abandon GHC-7, it should be made really clear – the base dependency bumped and all #if MIN_VERSION_ghc(8,0,0) removed.

leftaroundabout added a commit to leftaroundabout/IHaskell that referenced this pull request Sep 6, 2017

Reflect lack of support for GHC<8 in the dependencies.
As per gibiansky#716, GHC-7 support has at the moment no priority. Use the GHC7 tag
for the last version that retains the original GHC-7.10 support.

https://github.com/gibiansky/IHaskell/releases/tag/GHC7

(However, it is still quite feasible to support GHC-7.10 in master, see
gibiansky#747.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment